CUPRINS Prefață la ediția rusă cinci Cuvânt înainte Capitolul TEST DE AUTOEVALUAREA Capitolul PSIHOLOGIA ȘI ECONOMIA TESTĂRII DECLARAȚIA DE PROGRAM Economia testării Principii de testare Literatură Capitolul INSPECȚII, VISUALIZĂRI DE PROGRAMARE ȘI REVIZIUNI DE PROGRAME Inspecții și vederi de trecere - Inspecții text sursă - Lista de întrebări pentru a identifica erorile când inspectii = Prin vederi ' Verificarea la masa Evaluare prin revizuire Literatură Capitolul PROIECTAREA TESTEI Testarea prin acoperirea logicii programului Partiționare echivalentă Analiza valorii limită - Utilizarea diagramelor funcționale Estimare eroare Strategie - Literatură - Capitolul TESTAREA MODULELOR - Design de testare Testare pas cu pas Testarea descendentă și ascendentă a Executarea testului Literatură Capitolul TESTAREA COMPLEXELOR SOFTWARE Testarea funcției - Testarea sistemului Teste de acceptare Testarea instalării corecte Planificarea și controlul testelor Criterii de finalizare a testelor Literatura agențiilor independente de testare Capitolul DEBUG Metode de „forță brută” Metoda de inducție metoda deducerii Metoda de testare inversă a logicii de urmărire Principii de depanare Analiza erorilor Literatură Literatură adăugată în timpul traducerii Index de subiecte G Myers SHZhSіgIVO tіstіyunіnіm OGOGIPRD/ZHM Traducere din engleză editată de B A Pozina • • •• G Moscova „Finanțe și statistică” BBK M Traducători: S A Blau, S G Orlov, B A Pozin, L S Chernyak Myers G M Arta de a testa programe / Per din engleză, ed B A Lozina - M : Finanţe şi statistică, - p , ill k Cartea prezintă în linii mari și destul de popular principiile de bază ale metodologiei de testare pentru programele de depanare Sunt luate în considerare problemele de psihologie și economia testării Un loc semnificativ este acordat metodelor de ajustare a programelor Pentru profesioniștii implicați programare, studenți la absolvenți care studiază computerele *■' - {D * X| Y este nevalid; ar trebui scris ca (I>X) | (I>Y) Când comparăm trei numere pentru egalitate, expresia IF(A = = B = C) înseamnă ceva complet diferit Dacă este necesară verificarea relației matematice X>Y>Z, expresia (X>Y)&(Y>Z) va fi corectă Compară programul mantisele sau numerele în virgulă mobilă care sunt reprezentate în mașină în formă binară? Aceasta este uneori o sursă de erori din cauza trunchierii cifrelor cel mai puțin semnificative și din cauza egalității inexacte a numerelor în reprezentări binare și zecimale Sunt corecte ipotezele despre ordinea evaluării și succesiunea operatorilor pentru expresiile care conțin mai mult de un operator boolean? Cu alte cuvinte, dacă expresia (A= )&(B= ) | (C= ), este clar care dintre operații se efectuează prima: ȘI sau SAU? Modul în care un anumit compilator execută expresii booleene afectează rezultatul execuției programului? De exemplu, operatorul DACĂ (X=/= ) și ((Y/X)>Z) este acceptabilă pe unele compilatoare PL/ (adică, compilatoare care nu mai verifică de îndată ce una dintre expresiile din funcția AND este evaluată ca falsă), dar va avea ca rezultat o împărțire cu pe alte compilatoare Erori în transferurile de control Dacă programul conține un comutator (de exemplu, instrucțiunea GO TO calculată în Fortran), poate valoarea indexului să depășească vreodată numărul de salturi posibile? De exemplu, voi lua întotdeauna valoarea , sau în operatorul Fortran GO TO ( , , ), /? Va fi în cele din urmă finalizat fiecare ciclu? Veniți cu o dovadă informală sau cu argumente care să susțină finalizarea lor Programul, modulul sau subprogramul va fi în cele din urmă finalizat? Este posibil ca din cauza condițiilor prealabile, bucla să nu poată fi executată niciodată? Dacă da, este aceasta o neglijență? De exemplu, ce se întâmplă cu buclele care încep cu instrucțiuni FACEȚI CÂND (NEGĂSIT) DO I=X LA Z dacă valoarea inițială a lui NOTFOUND este falsă sau dacă X este mai mare decât Z? Pentru buclele controlate atât de numărul de iterații, cât și de o condiție booleană (de exemplu, o buclă pentru a organiza o căutare), care este secvența „scufundare în corpul buclei”? De exemplu, ce se întâmplă cu o buclă cu titlu FACEȚI = APOI MĂRIMĂ TABUL CÂND (NEGĂSIT) dacă NOTFOUND nu evaluează niciodată ca fals? Există erori „excepționale” (de exemplu, prea multe sau prea puține iterații)? Dacă limbajul de programare conține conceptul grupuri de declarații (de exemplu, DO sunt grupuri din PL/ limitate de instrucțiuni DO, END), există o declarație END explicită pentru fiecare grup și instrucțiunile END corespund grupurilor lor? Există soluții implicite? De exemplu, să presupunem că un parametru de intrare este de așteptat să fie , sau Este atunci logic să presupunem că ar trebui să fie dacă nu este sau ? Dacă este așa, presupunerea este corectă? Erori de interfață Este numărul de parametri primiți de modulul în cauză egal cu numărul de argumente transmise de fiecare dintre modulele apelante? Este corectă comanda lor? Atributele (cum ar fi tipul și dimensiunea) fiecărui parametru se potrivesc cu atributele argumentului său corespunzător? Unitățile fiecărui parametru se potrivesc cu unitățile argumentelor corespunzătoare? De exemplu, există cazuri în care valoarea parametrului este în grade și argumentul este în radiani? Numărul de argumente transmise de la modulul în cauză către alt modul este egal cu numărul de parametri așteptați în modulul apelat? Atributele fiecărui argument transmis altui modul se potrivesc cu atributele parametrului corespunzător din modulul în cauză? Unitățile fiecărui argument transmis altui modul se potrivesc cu unitățile parametrului corespunzător din modulul în cauză? Dacă sunt apelate funcții încorporate, numărul, atributele și ordinea argumentelor sunt corecte? Dacă un modul are mai multe puncte de intrare, parametrul este întotdeauna trecut indiferent de punctul de intrare? O astfel de eroare apare în a doua instrucțiune de atribuire a următorului program PL/ : A: PROCEDURĂ (W, X); W=X+ ; ÎNTOARCERE; B: INTRARE(Y,Z); Y=X+Z; SFÂRŞIT; Modificarea subrutinei este un parametru care ar trebui folosit doar ca valoare de intrare? Dacă există variabile globale (de exemplu, variabile în PL/ cu un atribut EXTERN, variabile specificate în instrucțiunile FORTRAN COMM ON), au aceleași definiții și atribute în toate modulele care le accesează? Sunt constantele transmise ca argumente? În unele implementări ale Fortran, declarații precum Apelați SUBX (J, ) sunt periculoase deoarece dacă subrutina SUBX atribuie o valoare celui de-al doilea parametru, valoarea constantei va fi modificată Erori I/O Sunt corecte atributele fișierelor declarate explicit? Sunt corecte atributele declarației OPEN? Specificațiile de format sunt de acord cu informațiile din instrucțiunile I/O? De exemplu, fiecare instrucțiune FORMAT se potrivește (în ceea ce privește numărul de date elementare și atributele acestora) cu instrucțiunile corespunzătoare READ și WRITE dintr-un program Fortran? Același lucru este valabil și pentru verificarea corespondenței dintre o listă de date și o listă de formate în instrucțiunile PL/ I/O Dimensiunea înregistrării este egală cu dimensiunea zonei de memorie pentru I/O? Toate fișierele sunt deschise înainte de a le folosi? Sunt semnele de sfârșit de dosar detectate și interpretate corect? Sunt stările de eroare I/O tratate corect? Există erori semantice sau gramaticale în textul afișat de program în imprimare sau pe ecran? Alte tipuri de control Dacă compilatorul produce un tabel de referințe încrucișate ale identificatorilor, verificați valorile care nu sunt menționate în această listă sau există o singură referință Dacă compilatorul produce o listă de atribute, verificați atributele fiecărei valori pentru a vă asigura că Garantați că nu există atribute neașteptate sau lipsă în program Dacă programul este compilat cu succes, dar compilatorul produce unul sau mai multe mesaje de „avertismente” sau „informații”, verificați cu atenție fiecare dintre ele Avertismentul indică faptul că compilatorul este „suspect” cu privire la corectitudinea acțiunilor dvs Toate aceste „suspiciuni” trebuie luate în considerare Mesajele informaționale pot enumera variabile nedeclarate sau constructe de limbaj care împiedică optimizarea codului Este programul (sau modulul) suficient de stabil? Cu alte cuvinte, își validează datele de intrare? Lipsește vreo funcție din program? O listă sumar de întrebări pentru identificarea erorilor este prezentată în fig și MANIPULAREA DATELOR Sunt utilizate variabile cu valori nesetate? Indicii se află în afara limitelor date? Există indici non-întregi? Există contestații „atârnate”? Sunt atributele corecte pentru toate aliasurile? Se potrivesc atributele înregistrării și structurii? Sunt adresele șirurilor de biți calculabile? Sunt șirurile de biți transmise ca argumente? Sunt corecte atributele de memorie de bază? *nouă Definițiile structurii care îi sunt date în diferite proceduri corespund între ele? Limita de linie a fost depășită? Există și alte erori în operațiunile de indexare sau la accesarea tablourilor după index? calculele Se calculează variabilele nearitmetice? Se fac calcule folosind diferite tipuri de date? Există calcule pentru variabile de lungimi diferite? Este lungimea rezultatului mai mică decât lungimea valorii calculate? Este posibil să se reverse sau să se piardă un rezultat intermediar în timpul calculului? Există împărțire la zero? Există inexactități atunci când lucrați cu numere binare? Valoarea variabilei este în afara intervalului setat? Este clară ordinea operatorilor? Este corectă împărțirea numerelor întregi? DESCRIEREA DATELOR COMPARAŢIE Sunt descrise toate variabilele? Este clară absența atributelor? Este corectă inițializarea? matrice de rânduri și șiruri de caractere? Dimensiunea, tipul și clasa de stocare sunt definite corect? Este inițializarea în concordanță cu clasa de stocare? Se poate face fără variabile cu nume similare? Se compară valorile tipurilor incompatibile? Sunt comparate cantități de diferite tipuri? Relațiile de comparație sunt corecte? Sunt corecte expresiile booleene? Se combină comparațiile și expresiile booleene? Se compară mărimile fracționale în formă binară? Este clară ordinea operatorilor? Este clară procedura de analizare a expresiilor booleene de către compilator? Orez Lista de verificare consolidată a întrebărilor pentru identificarea erorilor de inspecție (Partea ) TRANSFERUL CONTROLULUI Valoarea indexului dintr-un buton radio poate depăși numărul de tranziții? Va fi finalizat fiecare ciclu? Va fi finalizat programul? Există vreo buclă care eșuează din cauza condițiilor prealabile? Sunt corecte posibilele scufundări din ciclu? Există erori în abaterea numărului de iterații de la normă? Se potrivesc declarațiile DO și END? Există soluții implicite? INTERFATA Este numărul de parametri de intrare egal cu numărul de argumente? Se potrivesc atributele parametrilor și ale argumentelor? intrare ieșire Sunt corecte atributele fișierului? Sunt corecte afirmațiile ' OPEN? Formatul specificației se potrivește cu instrucțiunile I/O? Dimensiunea tamponului se potrivește cu dimensiunea înregistrării? Fișierele sunt deschise înainte de a le folosi? Sunt detectate semnele de sfârșit de fișier? Sunt detectate erori I/O? Există erori de text în rezultat? ALTE CONTROALE Există variabile în tabelul de referințe încrucișate care nu sunt referite? INTERFATA ALTE CONTROALE Unitățile de parametri și argumente se potrivesc? Numărul de argumente transmise modulelor apelate este egal cu numărul de parametri? Atributele argumentelor transmise modulelor apelate se potrivesc cu atributele parametrilor? Unitățile argumentelor transmise modulelor apelate se potrivesc cu unitățile parametrilor? Numărul, atributele și ordinea argumentelor sunt corecte pentru funcțiile încorporate? Există acces la parametri care nu au legătură cu punctul de intrare curent? Subrutina modifică argumentele care sunt doar intrări? Sunt definițiile variabilelor globale consecvente în toate modulele care le folosesc? Sunt constantele transmise ca argumente? Lista de atribute este conform așteptărilor? Există avertismente sau mesaje informative? Se efectuează controlul corectitudinii datelor de intrare? Lipsesc caracteristici? Orez Lista consolidată de întrebări pentru identificarea erorilor de inspecție (partea ) VIZIONĂRI ÎN CRUCE Revizuirea end-to-end, ca și inspecția, este un set de proceduri și metode de detectare a erorilor, efectuate de un grup de persoane care examinează textul programului O astfel de revizuire are multe în comun cu procesul de inspecție, dar procedurile lor sunt oarecum diferite și, în plus, aici sunt folosite și alte metode de detectare a erorilor Asemenea unei inspecții, o examinare este efectuată ca o sesiune continuă care durează una sau două ore See Through Team - este format din - persoane Este format dintr-un președinte, ale cărui funcții sunt similare cu cele ale unui președinte dintr-un grup de inspecție, un secretar care notează toate erorile constatate și un specialist în teste Opiniile diferă cu privire la cine ar trebui să fie al patrulea și al cincilea membru al grupului Desigur, unul dintre ei trebuie să fie programator În ceea ce privește al cincilea participant, există următoarele ipoteze: ) un programator înalt calificat; ) un expert în limbaj de programare; ' ) un începător (al cărui punct de vedere nu este influențat de experiența anterioară); ) persoana care în cele din urmă va opera programul; ) un participant la un alt proiect; ) cineva din același grup de programatori ca și autorul programului Procedura inițială pentru o prezentare este aceeași ca și pentru o inspecție: materialele sunt distribuite participanților în avans, cu câteva zile înainte de întâlnire, permițându-le să se familiarizeze cu programul Cu toate acestea, procedura ședinței este diferită de procedura ședinței de inspecție În loc să citească pur și simplu textul programului sau să folosească o listă de erori, participanții la întâlnire „acţionează ca un computer” Testerul desemnat prezintă audienței un număr mic de teste pe hârtie care reprezintă seturi de intrări (și ieșiri așteptate) pentru un program sau modul În timpul întâlnirii, fiecare test este efectuat mental Aceasta înseamnă că datele de testare sunt procesate conform logicii programului Starea programului (adică, valorile variabilelor) este urmărită pe hârtie sau pe tablă Desigur, numărul de teste trebuie să fie mic și trebuie să fie de natură simplă, deoarece viteza de execuție a unui program uman este cu multe ordine de mărime mai mică decât cea a unei mașini Prin urmare, testele în sine nu joacă un rol critic, ci mai degrabă servesc ca mijloc pentru înțelegerea inițială a programului și ca bază pentru a întreba programatorul despre logica de proiectare și ipotezele făcute În majoritatea recenziilor end-to-end, atunci când rulează testele în sine, ei găsesc mai puține erori decât atunci când intervievează un programator Ca și în cazul unei inspecții, opinia participanților este factorul decisiv Comentariile ar trebui abordate la program, nu la programator Cu alte cuvinte, greșelile nu sunt văzute ca o slăbiciune a persoanei care le-a făcut Ele mărturisesc complexitatea procesului de creare a programelor și sunt rezultatul naturii încă primitive a metodelor de programare existente Trecerile ar trebui să se desfășoare în același mod ca procesul de inspecție descris mai devreme Efectele secundare care apar în timpul acestui proces (identificarea părților predispuse la erori ale programului și învățarea din analiza erorilor, stilul și metodele) sunt, de asemenea, caracteristice procesului de parcurgere VERIFICAREA LA MASĂ A treia metodă de detectare manuală a erorilor este „verificarea la masă” folosită mai devreme decât alte metode Verificările din tabel pot fi considerate ca verificări ale codului sursă sau proceduri detaliate, efectuate de o singură persoană care citește codul programului, îl verifică cu o listă de erori și/sau rulează date de testare prin program În cea mai mare parte, verificarea la masă este relativ neproductivă Acest lucru se datorează în primul rând faptului că o astfel de verificare este un proces complet dezordonat Al doilea motiv, mai important, este că testarea pe tabel este opusă unuia dintre principiile de testare din Cap , conform căruia programatorul își testează de obicei propriile programe în mod ineficient Prin urmare, verificarea tabelului poate fi făcută cel mai bine de către o altă persoană decât autorul programului (de exemplu, doi programatori pot schimba programe în loc să își verifice propriile programe la masă), dar chiar și atunci o astfel de verificare este mai puțin eficientă decât trecerea sau inspecții Acest motiv este motivul principal pentru formarea unui grup în timpul revizuirilor sau inspecțiilor end-to-end ale textului sursă Întâlnirea grupului este favorabilă creării unei atmosfere de competiție sănătoasă: participanții doresc să-și arate cea mai bună parte în găsirea erorilor Când verificați la masă, acest efect valoros, desigur, lipsește Pe scurt vorbind Apropo de asta, verificările în tabel sunt cu siguranță utile, dar sunt mult mai puțin eficiente decât inspecțiile codului sursă sau trecerile EVALUARE PRIN VIZIONARE Ultimul proces manual de revizuire a programului nu este despre testarea programului (adică scopul său nu este de a găsi erori) Cu toate acestea, acest proces este descris aici deoarece este legat de ideea de „citire a unui text Evaluarea revizuirii [ ] este o metodă de evaluare a unui program anonim în ceea ce privește calitatea generală, mentenabilitatea, extensibilitatea, mentenabilitatea și claritatea acestuia Scopul acestei metode este de a oferi programatorului un mijloc de autoevaluare Un programator este selectat pentru a acționa ca administrator de proces Administratorul, la rândul său, selectează aproximativ - de participanți ( este numărul minim pentru păstrarea anonimatului) Se așteaptă ca membrii să fie de același profil (de exemplu, programatorii COBOL și programatorii sistemului Assembler nu trebuie grupați împreună) Fiecare participant este rugat să trimită spre considerare două dintre programele sale: cel mai bun (din punctul său de vedere) și de proastă calitate Programele selectate sunt distribuite aleatoriu între participanți Li se oferă patru programe pentru a fi luate în considerare Două dintre ele sunt „cele mai bune” și două sunt „cele mai proaste”, dar recenzentului nu i se spune ce program aparține cărui grup Fiecare participant petrece de minute urmărind un program și completează un chestionar pentru a-l evalua După vizualizarea tuturor celor patru programe, calitatea lor relativă este evaluată Chestionarul de evaluare cere evaluatorului să evalueze programul pe o scară de șapte puncte ( pentru un „da sigur”, pentru un „nu” definit), ca răspuns la, de exemplu, următoarele întrebări: A fost programul ușor de înțeles? Au fost rezultatele proiectului la nivel înalt clare și acceptabile? Au fost rezultatele proiectării la nivel scăzut ■evidente și acceptabile? Vă este ușor să modificați acest program? Ați simți satisfacția de a scrie un astfel de program? De asemenea, evaluatorului i se cere să furnizeze comentarii generale și recomandări pentru îmbunătățirea programului După vizionare, fiecărui participant i se oferă un chestionar anonim cu o evaluare a celor două programe ale sale Participanții primesc un rezumat statistic care conține o clasificare generală și detaliată a propriilor programe în comparație cu setul complet de programe și o analiză a modului în care evaluările altor programe se potrivesc cu evaluările acelorași programe oferite de alți evaluatori Scopul unei astfel de revizuiri este de a permite programatorilor să-și evalueze propriile calificări Această metodă pare să fie utilă atât pentru aplicații industriale, cât și pentru educație LITERATURĂ Weinberg G M Psihologia programării computerelor New York, Van Nostrand Reinhold, Fiabilitatea software-ului Myers GJ: principii și practici New York, Wiley-Interscience, Traducere rusă: Myers G Software Reliability M , Mir, Muers GJ Compozit/Design structurat New York, Van Nostrand Reinhold, MyersG J Un experiment controlat în testarea programelor și procedurile/inspecțiile codului - comun ACM, , ( ), p - cinci Perriens MP O aplicație a inspecției formale pentru dezvoltarea programelor structurate de sus în jos — RADC—TR— — , IBM Federal System Div , Gaithersburg, Md , (NTIS AD/A— ) € S boom an M L, B o s ku MI Tipuri, distribuție și timpi de testare și corectare pentru erori de programare — Proceedings of the International Conference on Reliable Software New York, IEEE, , p - F agan ME Design și inspecții de cod pentru a reduce erorile în dezvoltarea programului — IBM Systems J , , ( ), p - Freeman R D Un experiment în dezvoltarea software-ului — The Beli System Technical Journal, Special Safeguard Supplement, , p SI -S Ascol în J şi colab Specificație de inspecție cod — TR- , IBM System Communication Division, Kingston, NY, R A nderson N și Shneiderman B Utilizarea evaluărilor de la egal la egal în evaluarea calității programelor de calculator - IFSM-TR- , Universitatea din Maryland, CAPITOLUL PROIECTARE DE TESTARE Rezultatele cercetărilor psihologice discutate în Cap arată că cel mai mare accent în testarea software-ului este pe proiectarea sau crearea de teste eficiente Acest lucru se datorează imposibilității testării „complete” a programului, adică un test pentru orice program va fi neapărat incomplet (cu alte cuvinte, testarea nu poate garanta absența tuturor erorilor) Strategia de proiectare este de a încerca să reduceți pe cât posibil această „incompletitudine” Dacă introduceți restricții privind timpul, costul, timpul mașinii etc , atunci următoarea devine întrebarea cheie a testării: Care dintre toate testele posibile are cea mai mare probabilitate de a găsi cele mai multe erori? Un studiu al metodologiilor de proiectare a testelor oferă un răspuns la această întrebare Aparent, cea mai proastă dintre toate metodologiile este testarea cu valori aleatorii de intrare (stochastice) - procesul de testare a unui program prin alegerea aleatorie a unui subset dintre toate valorile de intrare posibile În ceea ce privește probabilitatea de a găsi majoritatea erorilor, un set de test selectat aleatoriu are o probabilitate scăzută de a fi un subset optim sau aproape optim Acest capitol discută mai multe abordări care vă permit să selectați mai inteligent datele de testare În cap , s-a arătat că testarea exhaustivă a cutiei negre sau a cutiei albe nu este în general posibilă Cu toate acestea, sa observat că o strategie de testare acceptabilă poate avea elemente ale ambelor abordări Un astfel de jav Aceasta este strategia prezentată în acest capitol Este posibil să se dezvolte un test destul de complet utilizând o anumită metodologie de proiectare cu cutie neagră și apoi să o completeze cu un test al logicii programului (adică, folosind metode cu caseta albă) Metodologiile discutate în acest capitol sunt prezentate mai jos Cutie neagră Diviziunea echivalentă Analiza valorilor la limită Aplicarea diagramelor funcționale Eroare de ghicire cutie alba Acoperire operator Acoperirea soluției Acoperirea stării Acoperire de decizie/condiție Acoperirea combinatorie a condițiilor Deși metodele enumerate vor fi luate în considerare separat aici, atunci când se proiectează un test de program eficient, se recomandă utilizarea dacă nu toate aceste metode, atunci cel puțin majoritatea, deoarece fiecare metodă are anumite avantaje și dezavantaje (de exemplu, capacitatea pentru a detecta și a sări peste diferite tipuri de erori) Adevărat, aceste metode sunt foarte laborioase, așa că unii experți, familiarizandu-se cu ele, ar putea să nu fie de acord cu această recomandare Cu toate acestea, trebuie înțeles că testarea unui program este o sarcină extrem de dificilă Pentru a ilustra acest lucru, să citam o zicală binecunoscută: „Dacă crezi că dezvoltarea și codarea unui program este un lucru dificil, atunci nu ai văzut încă nimic” Procedura recomandată este de a dezvolta teste folosind metode cutie neagră și apoi, ca o condiție prealabilă, teste suplimentare folosind metode cutie albă Metodele de cutie albă mai utilizate pe scară largă sunt discutate mai întâi TESTARE PRIN ACOPERIRE LOGICA PROGRAMULUI Testarea cutie albă este caracterizată prin măsura în care testele execută sau acoperă logica (codul sursă) a unui program Așa cum se arată în cap , testarea exhaustivă a casetei albe implică executarea fiecărei căi din program; dar din moment ce de obicei nu este fezabil să rulați fiecare cale într-un program cu bucle, testarea tuturor căilor nu este în scopul acestei cărți |o ca promitatoare eu Dacă refuzăm complet să testăm toate căile, atunci putem arăta că criteriul de acoperire este execuția fiecărei instrucțiuni a programului cel puțin o dată Din păcate, acesta este un criteriu slab, deoarece executarea fiecărei declarații cel puțin o dată este o condiție necesară, dar nu suficientă pentru o /=///? testarea mea de -— principiul cutiei albe (Fig ) Presupune ce este in fig reprezentare Un mic pro-d g m gram care ar trebui lena program mic de testat ma asta ar trebui sa fie testat Programul echivalent scris în PL/ este: M: PROCEDURA (A, B, X); DACA ((A > ) & (B= )) ATUNCI FACETI; X=X/A; SFÂRŞIT; DACA ((A= ) I (X> )) ATUNCI FACETI; X=X+I; SFÂRŞIT; SFÂRŞIT; SFÂRŞIT; Este posibil să se execute fiecare instrucțiune prin scrierea unui singur test care ar implementa calea as Cu alte cuvinte, dacă punctul a ar fi setat la A = , B = și X = , fiecare instrucțiune ar fi executată o dată (de fapt, X poate lua orice valoare) Din păcate, acest criteriu este mai rău decât pare prima vedere De exemplu, să fie scrisă prima soluție ca sau, nu ca și La testarea conform acestui criteriu, această eroare nu va fi detectată Fie ca a doua soluție să fie scrisă în program ca X> ; nici această eroare nu va fi prinsă În plus, există o cale în care X nu se schimbă (cale abd) Dacă există o eroare, atunci aceasta nu va fi detectată Astfel, criteriul de acoperire a operatorului este atât de slab încât nu este utilizat în mod obișnuit O măsură mai puternică a acoperirii logicii programului este cunoscută sub denumirea de acoperire de decizie sau acoperire de tranziție Conform acestui criteriu, trebuie scris un număr suficient de teste astfel încât fiecare soluție a acestor teste să fie evaluată la adevărat și fals cel puțin o dată Cu alte cuvinte, fiecare direcție de tranziție trebuie implementată cel puțin o dată Exemple de instrucțiuni de salt sau de decizie sunt instrucțiuni DO (sau PERFORM UNTIL în Cobol), IF, cu mai multe ieșiri GO TO Se poate demonstra că acoperirea soluției îndeplinește de obicei criteriul de acoperire a operatorului Deoarece fiecare instrucțiune se află pe o cale, fie dintr-o instrucțiune de salt, fie dintr-un punct de intrare în program, fiecare instrucțiune trebuie să fie executată atunci când fiecare direcție de salt este executată Cu toate acestea, există cel puțin trei excepții Prima este o situație patologică în care programul nu are soluții Al doilea apare în programe sau subrutine cu mai multe puncte de intrare; această instrucțiune poate fi executată numai dacă execuția programului începe de la punctul de intrare corespunzător A treia excepție o reprezintă operatorii din unitățile ON; executarea fiecărei direcții de salt nu va determina neapărat executarea tuturor unităților ON Deoarece acoperirea declarațiilor este considerată o condiție necesară, acoperirea deciziei, care pare a fi un criteriu mai puternic, trebuie să includă acoperirea declarațiilor Prin urmare, acoperirea deciziei necesită ca fiecare decizie să fie evaluată la adevărat și fals și ca fiecare declarație să fie executată cel puțin o dată O modalitate alternativă și mai ușoară de a exprima această cerință este ca fiecare decizie să fie evaluată la adevărat și fals și că fiecare punct de intrare (inclusiv unitățile ON) trebuie dar controlul nu este transferat atunci când programul este apelat cel puțin o dată Cele de mai sus presupune doar soluții sau tranziții cu două valori și trebuie modificate pentru programele care conțin soluții cu mai multe valori Exemple de astfel de programe sunt programele PL/ care includ instrucțiuni SELECT (CASE) sau instrucțiuni GO TO folosind etichete de variabile, programe Fortran cu instrucțiuni IF aritmetice, instrucțiuni GO TO calculate sau instrucțiuni GO TO pe bază de prescripție și programe Cobol care conțin GO Instrucțiuni TO împreună cu instrucțiuni ALTER sau GO-TO-DEPENDING-ON Criteriul pentru acestea este îndeplinirea fiecărui rezultat posibil al tuturor deciziilor privind; cel puțin o dată și transferați controlul atunci când apelați programul sau subrutinele la fiecare punct de intrare cel puțin o dată În programul prezentat în fig , acoperirea deciziei se poate face prin două teste care acoperă fie căile ace și abdb, fie căile aed și abe Dacă alegem ultima acoperire alternativă, atunci intrările celor două cazuri de testare sunt L= , B= , X= și A= , B= , X=/ Acoperirea deciziei este un criteriu mai puternic decât acoperirea operatorului, dar are și dezavantajele sale De exemplu, o cale în care X nu se schimbă (dacă este selectată prima acoperire alternativă) va fi testată cu o probabilitate de % Dacă există o eroare în a doua soluție (de exemplu, X ), atunci eroarea nu va fi detectată de cele două teste din exemplul anterior Un criteriu mai bun în comparație cu cel anterior este acoperirea stării În acest caz, se înregistrează un număr suficient de teste, astfel încât toate rezultatele posibile ale fiecărei condiții din soluție să fie executate cel puțin o dată Deoarece, ca și în cazul acoperirii deciziilor, această acoperire nu duce întotdeauna la execuția fiecărei instrucțiuni, este necesară o adăugare la criteriu, care constă în faptul că fiecare punct de intrare în program sau subrutină, precum și unitățile ON Nu există astfel de operatori în PL/ , dar pot fi implementați folosind instrumente PL/ Metodele de implementare sunt descrise în cartea: Hughes J , M și ch tom J Abordarea structurală a programării M , Mir, - Notă pe controlul trebuie transferat atunci când este apelat cel puțin o dată De exemplu, instrucțiunea buclă DO K—O TO WHILE (J+K (adică, execuția ultimei iterații a buclei), /+/ , B= , A= și X> Prin urmare, este necesar un număr suficient de teste, cum ar fi pentru a realiza situații în care D> , E £> = și B=d= în punctul „uA = , A=^ , X> și I TABSIZE and NOTFOUND este adevărat (se ajunge la sfârșitul tabelului fără a găsi valoarea dorită) I>TABSIZE și NOTFOUND sunt false (valoarea pe care o căutați este ultima intrare din tabel) Este ușor de observat că o suită de teste care satisface criteriul de acoperire a condiției combinatorii satisface și criteriile de acoperire a deciziei, acoperirea condiției și criteriile de acoperire a deciziei/condiții Conform acestui criteriu, în programul din Fig următoarele opt combinații ar trebui să fie acoperite de teste: J A> , B= A> , B¥= A^I, B= Asgl, B^O A= , X> A= , Xsal A=A= , X> A¥= , X^I Rețineți că combinațiile - sunt valorile celei de-a doua instrucțiuni IF Deoarece X poate fi schimbat înainte de executarea acestei instrucțiuni, valorile necesare pentru testarea acesteia trebuie restaurate din logica programului pentru a găsi valorile de intrare adecvate Nu este necesar să folosiți toate cele opt teste pentru a testa aceste combinații De fapt, ele pot fi acoperite de patru teste Iată valorile de testare de intrare și combinațiile pe care le acoperă: A = , B = , X= A= , B= , X= A= , B= , X= A = , B = , X= coperți coperți coperți coperți Faptul că cele patru teste corespund la patru căi diferite din Fig este o coincidență De fapt, testele de mai sus nu acoperă toate căile, ele omit calea aed De exemplu, sunt necesare opt teste pentru a testa următorul program: DACĂ((X=Y) & (LUNGIME(Z)= ) & SFÂRȘIT) ATUNCI J=l; ELSE = ; deși este acoperit doar în două moduri În cazul buclelor, numărul de teste pentru a satisface criteriul de acoperire a condiției combinatorii este de obicei mai mare decât numărul de căi Astfel, pentru programele care conțin o singură condiție per decizie, criteriul minim este unul a cărui suită de teste ) face ca toate rezultatele fiecărei decizii să fie executate cel puțin o dată și ) trece controlul fiecărui punct de intrare (de exemplu, punct de intrare, ON) - unitate) cel puțin o dată (pentru a se asigura că fiecare instrucțiune de program este executată cel puțin o dată) Pentru programele care conțin soluții, fiecare dintre ele având mai mult de o condiție, criteriul minim constă într-un set de teste care provoacă toate combinații ale rezultatelor condițiilor, în fiecare decizie, și trecerea controlului către fiecare punct de intrare al programului cel puțin o dată [Cuvântul „posibil” este folosit aici deoarece unele combinații de condiții pot să nu fie realizabile; de exemplu, în expresia (L> ) & (L ) Dacă condiția de intrare descrie numărul de valori (de exemplu, „de la una la șase persoane pot merge într-o mașină”), atunci se determină o clasă de echivalență corectă și două incorecte (niciuna și mai mult de șase persoane) Dacă condiția de intrare descrie un set de valori de intrare și există motive să credem că programul interpretează fiecare valoare într-un mod special (de exemplu, „există modalități cunoscute de a călători cu AUTOBUZ, CAMION, TAXI, PICIOARE, sau MOTOCICLETĂ”), atunci se determină clasa de echivalență corectă pentru fiecare valoare și o clasă de echivalență greșită (de ex , „Pe o remorcă”), Dacă condiția de introducere descrie o situație „trebuie să fie” (de exemplu, „primul caracter al identificatorului trebuie să fie o literă”), atunci se definește o clasă de echivalență corectă (primul caracter este o literă) și una este incorectă (primul caracter nu este o literă) Dacă există vreun motiv să credem că diferite elemente ale unei clase de echivalență sunt tratate diferit de program, atunci această clasă de echivalență este împărțită în clase de echivalență mai mici Acest proces va fi ilustrat pe scurt mai jos Teste de clădire Al doilea pas este utilizarea claselor de echivalență pentru a construi teste Acest proces include: - Atribuiți un număr unic fiecărei clase de echivalență Proiectarea de noi teste, fiecare dintre acestea să acopere cât mai multe clase de echivalență obișnuite neacoperite posibil, până când toate clasele de echivalență valide sunt acoperite de teste (dar nu comune) Scrieți teste, fiecare acoperind una și numai una dintre clasele de echivalență greșite descoperite, până când toate clasele de echivalență greșite sunt acoperite de teste Motivul pentru acoperirea claselor de echivalență greșite cu teste individuale este că anumite verificări cu intrări greșite ascund sau înlocuiesc alte verificări cu intrări greșite De exemplu, specificația menționează „tipul cărții la căutare (INGINERIA INFORMATICĂ, PROGRAMARE sau GENERAL) și numărul ( - )” Apoi testați XYZ Despre afișează două condiții eronate (tipul de carte și cantitate greșită) și probabil că nu va verifica cantitatea, deoarece programul ar putea răspunde „XYZ ESTE UN TIP DE CARTE INEXISTENT” și să nu verifice restul intrării Exemplu Să presupunem că atunci când se dezvoltă un compilator pentru un subset al limbajului Fortran, este necesar să se testeze verificarea sintactică a operatorului DIMENSION Specificația este dată mai jos (Această declarație nu este o instrucțiune completă Fortran DIMENSION; specificația a fost mult redusă pentru a face din ea un „studiu de caz” Nu trebuie să credem că testarea programelor reale este la fel de ușoară ca exemplele din această carte ) , denotă unități sintactice că în declarațiile reale trebuie înlocuite cu valorile corespunzătoare, elementele opționale sunt cuprinse între paranteze drepte, o elipsă indică faptul că elementul care îl precede poate fi repetat de mai multe ori la rând Operatorul DIMENSION este folosit pentru a defini matrice Forma operator DIMENSION: DIMENSION anunț [,ad] unde ad este un descriptor de matrice în formular n(d[,d] ), n este numele simbolic al matricei, iar d este indexul matricei Simbol Numele personale pot conține de la unu la șase caractere, fie litere, fie cifre, cu o literă mai întâi Sunt permisi de la unu la sapte indici Formular index [lb:]ub, unde Іб și ub stabilesc limitele inferioare și superioare ale indexului matricei Limita poate fi fie o valoare constantă de la - la , fie o variabilă întreagă (fără indice) Dacă Іб nu este definit, atunci se presupune că este egal cu unu Valoarea lui ub trebuie să fie mai mare sau egală cu Іb Dacă Іб este definit, atunci poate avea o valoare negativă, zero sau pozitivă Ca toate instrucțiunile, instrucțiunea DIMENSION poate fi continuată pe mai multe rânduri (Sfârșit specificația ) Primul pas este identificarea condițiilor de intrare și determinarea claselor de echivalență din acestea (Tabelul ) Clasele de echivalență din tabel sunt indicate prin numere Următorul pas este construirea unui test care să acopere una sau mai multe clase de echivalență valide De exemplu, testați DIMENSIUNEA A( ) acoperă clasele , , , , , , , , și În continuare, sunt definite unul sau mai multe teste care acoperă clasele de echivalență valabile rămase Da, testează DIMENSIUNEA A (I, ,J XXXX , ,KLM, X ),BBB(— : , : , : , : ) acoperă clasele rămase Enumerăm clasele de echivalență incorecte și testele corespunzătoare: ( ) (cinci) ( ) (nouă) (ȘI) ( ) (paisprezece) ( ) (optsprezece) ( ) ( ) ( ) ( ) ( ) ( ) ( ) DIMENSIUNE DIMENSIUNE DIMENSIUNE DIMENSIUNE DIMENSIUNE DIMENSIUNE DIMENSIUNE DIMENSIUNE DIMENSIUNE DIMENSIUNE DIMENSIUNE DIMENSIUNE DIMENSIUNE DIMENSIUNE DIMENSIUNE ( ) A ( ) Al( ) la( ) LA B ( , , , , , , , ) B ( , A ( )) B( „ ) C(I , ) C( O, J) D(— : ) D( ) D( : ) D(A( ): ) D( : ) Aceste clase de echivalență sunt acoperite de teste Opțional, cititorul poate compara aceste teste cu un set de teste obținute printr-o metodă specială Deși partiția echivalentă este semnificativ mai bună decât selecția aleatorie a testelor, are totuși dezavantaje (adică, ratează anumite tipuri de teste de înaltă performanță) Următoarele două metode - analiza valorilor limită și utilizarea diagramelor funcționale (diagrame ale relațiilor cauză-efect, grafică cauză-efect) - sunt lipsite de multe dintre deficiențele inerente partiționării echivalente * Clase de echivalare Tabelul Cerințe preliminare Clase de echivalență corecte Clase de echivalență incorecte Numărul de descriptori de matrice unu ( ), > unul ( ) niciunul ( ) Lungimea numelui matricei - ( ) ( ), > ( ) Numele matricei conține altceva litere ( ) și cifre ( ) Numele matricei începe cu litera da ( ) nu ( ) Număr de indici — ( ) ( ), > ( ) Limită superioară constantă ( ), nume întreg al elementului de matrice variabila ( ) și ( ), altceva ( ) constă în ceva Numele întregii schimbări - are în componența sa litere NOAH ( ) și numere ( ) altfel ( ) Variabila întreagă începe cu litera da ( ) nu ( ) Constant - - ( ) ( ) Limita inferioară definită da ( ), nu ( ) Limită superioară pentru peste ( ), sub ( ) în raport cu limita inferioară este ( ) Valoarea grului inferior este negativă ( ) zero ( ), > ( ) Limita inferioară este o constantă ( ), un nume întreg al elementului de matrice variabilă ( ) va ( ), altceva ( ) Operator situat pe mai multe linii da ( ), nu ( ) ANALIZA VALORILOR LA LIMITĂ Experiența a arătat că testele care examinează condițiile la limită sunt mai utile decât testele care nu le examinează Condițiile limită sunt situații care apar direct pe, deasupra sau sub granițele claselor de echivalență de intrare și ieșire Analiza valorii limită diferă de partiţionarea echivalentă în două privinţe: Alegerea oricărui element din clasa de echivalență ca reprezentativ în analiza valorilor la limită se realizează astfel încât să se verifice fiecare graniță a acestei clase cu un test La elaborarea testelor, sunt luate în considerare nu numai condițiile de intrare (spațiul de intrare), ci și spațiul rezultat (adică, clasele de echivalență de ieșire) Este dificil de descris „bucătăria” analizei valorii la limită, deoarece necesită un anumit grad de creativitate și specializare în problema luată în considerare (De aceea, analiza valorii la limită, ca multe alte aspecte ale testării, se bazează în mare măsură pe inteligența umană ) Cu toate acestea, iată câteva reguli generale pentru această metodă Construiți teste pentru limitele regiunii și teste cu date de intrare incorecte pentru situații de depășire ușoară a regiunii dacă condiția de intrare descrie intervalul De exemplu, dacă intervalul corect de intrare este - , - , , atunci scrieți teste pentru situațiile - , , , , - , și , Construiți teste pentru valorile minime și maxime ale condițiilor și teste mai mari sau mai mici decât aceste valori dacă condiția de intrare satisface un set discret de valori De exemplu, dacă fișierul de intrare poate conține de la la de intrări, atunci obțineți teste pentru , , și de intrări Folosiți regula pentru fiecare condiție de ieșire De exemplu, dacă programul calculează o cheltuială lunară și dacă cheltuiala minimă este de , USD, iar cea maximă este de , USD, atunci creați teste care cheltuiesc de la , USD la , USD și , dolari De asemenea, construiți, dacă este posibil, teste care provoacă un flux negativ și un flux mai mare de , USD Rețineți că este important să verificați limitele spațiului rezultat, deoarece limitele regiunilor de intrare nu reprezintă întotdeauna același set de condiții ca limitele regiunilor de ieșire (de exemplu, când se ia în considerare o rutină de calcul sinus) De asemenea, nu este întotdeauna posibil să obțineți un rezultat în afara regiunii de ieșire, dar merită totuși luat în considerare Folosește regula pentru fiecare zi liberă termeni De exemplu, dacă sistemul de recuperare a informațiilor afișează cele mai relevante rezumate pe ecranul terminalului în funcție de interogarea de intrare, dar nu mai mult de patru rezumate, atunci construiți teste astfel încât programul să afișeze zero, unu și patru rezumate și un test care ar putea cauza programelor de execuție cu afișare eronată a cinci rezumate Dacă intrarea sau ieșirea programului este un set ordonat (de exemplu, un fișier secvențial, o listă liniară, un tabel), atunci concentrați-vă pe primul și ultimul element al acestui set Încearcă-ți mâna să găsești alte condiții limită Pentru a ilustra necesitatea analizei valorii la limită, se poate folosi programul de analiză a triunghiului dat în cap Pentru a defini un triunghi, valorile de intrare trebuie să fie numere întregi pozitive, iar suma oricăror două dintre ele trebuie să fie mai mare decât a treia Dacă sunt definite partiții echivalente, atunci este recomandabil să definiți o partiție în care această condiție este îndeplinită și o alta în care suma a două numere întregi nu este mai mare decât a treia Prin urmare, cele două teste posibile sunt - - și - - Cu toate acestea, există posibilitatea de a pierde o eroare aici Cu alte cuvinte, dacă expresia din program a fost codificată ca A+B^C în loc de A+B>C, atunci programul ne-ar spune în mod eronat că numerele - - reprezintă un triunghi echilateral regulat Astfel, diferența esențială dintre analiza valorii la limită și partiționarea echivalentă este aceea că analiza valorii la limită investighează situațiile care apar pe și în apropierea granițelor partițiilor echivalente Ca exemplu de aplicare a metodei de analiză a valorii la limită, luați în considerare următoarea specificație a programului MTEST este un program care sortează diverse informații despre examene Intrarea în program este un fișier numit OCR, care conține înregistrări de de caractere Prima intrare reprezintă titlul; conținutul său este folosit ca titlu al fiecărui raport de ieșire Următorul set de intrări descrie răspunsurile corecte la examen Fiecare intrare din acest set conține „ ” ca ultim caracter Prima intrare din coloanele - stabilește numărul de răspunsuri (ia valori de la până la ) Coloanele - conțin informații despre răspunsurile corecte la întrebările numerotate - (orice caracter este perceput ca un răspuns) Intrările ulterioare conțin în coloanele - informații despre răspunsurile corecte la întrebările numerotate - , - etc Al treilea set de intrări descrie răspunsurile fiecărui elev Nume Numărul de întrebări Răspunsuri corecte - BO Răspunsuri corecte - OO BO mden tiirika tor student student răspunde - Elevul răspunde - BO Eden și soia pe torul elevului Răspunsurile elevului - Yu BO Orez Structuri de înregistrări de intrare pentru programul MTEST dent; orice intrare din acest set are numărul „ ” în a optzecea coloană Pentru fiecare elev, prima intrare din coloanele - conține numele sau numărul acestuia (orice caractere); coloanele - conțin informații despre rezultatele răspunsurilor elevilor la întrebările cu numerele - Dacă testul are mai mult de de întrebări, atunci înregistrările ulterioare pentru elev descriu răspunsurile - , - etc în coloanele - Numărul maxim de elevi este de Formatele de înregistrare de intrare sunt prezentate în fig Intrările de ieșire sunt; ) un raport ordonat în ordinea lexicografică a identificatorilor elevilor și care arată calitatea răspunsurilor fiecărui elev (procent de răspunsuri corecte) și rangul acestuia; ) un raport similar, dar ordonat după calitate; ) un raport care arată media, mediana și abaterea standard a calității răspunsurilor; ) un raport sortat după numărul întrebării și care arată procentul de elevi care au răspuns corect la fiecare întrebare (Sfârșit specificația ) Să începem să citim metodic caietul de sarcini, identificând precondițiile Prima condiție de intrare la limită este un fișier de intrare gol A doua condiție de intrare este o hartă (înregistrare) a numelui; condiţiile la limită sunt Nu există carte de titlu, cele mai scurte și cele mai lungi titluri Următoarele condiții de introducere sunt prezența înregistrărilor de răspuns corect și prezența unui număr de câmpuri de întrebări în prima înregistrare a răspunsului - nu este o clasă de echivalență pentru numărul de întrebări, deoarece pentru fiecare subset de de intrări se poate întâmpla ceva specific (adică sunt necesare multe intrări) O împărțire acceptabilă a întrebărilor în clase de echivalență este o împărțire în două subseturi: - și - Prin urmare, sunt necesare teste în care câmpul pentru numărul de întrebări ia valori de , , , și Aceste teste acoperă majoritatea condițiilor limită pentru înregistrările de răspuns corect; cu toate acestea, există încă trei situații interesante — înregistrări fără răspuns, înregistrări pentru răspunsuri „multe răspunsuri la întrebare” și înregistrări pentru răspunsuri „puține răspunsuri la întrebare” (de exemplu, numărul de întrebări este de * și există trei înregistrări de răspunsuri în primul caz și o înregistrare de răspuns în al doilea) Astfel, sunt definite următoarele teste: Goliți fișierul de intrare Înregistrarea numelui lipsește Numele are un caracter Numele are de caractere Examen cu o singură întrebare Examen de de întrebări Examen de de întrebări Examen de de întrebări intrebari la examen Câmpul pentru numărul de întrebări are valori non-numerice I După înregistrarea numelui, nu există înregistrări ale corectului răspunsuri Există intrări precum „multe răspunsuri corecte la o singură întrebare” Există intrări precum „puține răspunsuri corecte la o singură întrebare” Următoarele condiții de introducere se aplică răspunsurilor elevilor Testele valorii la limită în acest caz ar părea a fi: elevi Cu valorile selectate ale câmpului numărul de întrebări, este mai interesant să luați în considerare nu , ci de întrebări - Notă pe elev de elevi elevi Există o singură intrare pentru răspunsul studentului, dar există două intrări pentru răspunsurile corecte Înregistrarea răspunsului elevului de mai sus este prima din dosar Înregistrarea răspunsului elevului de mai sus este ultimul din dosar Există două înregistrări ale răspunsurilor elevului, dar există o singură înregistrare a răspunsului corect Înregistrarea răspunsurilor elevului de mai sus este prima din dosar Înregistrarea răspunsurilor elevului de mai sus este ultima din dosar De asemenea, puteți obține un set de teste pentru a verifica limitele de ieșire, deși unele dintre limitele de ieșire (de exemplu, raportul gol ) sunt acoperite de testele date Condițiile limită pentru rapoartele și sunt sunt: elevi (la fel ca testul ); elev (la fel ca testul ); de elevi (la fel ca testul ) Estimările calității răspunsurilor tuturor elevilor sunt aceleași Estimările calității răspunsurilor tuturor elevilor sunt diferite Scorurile de calitate ale unora, dar nu tuturor elevilor sunt aceleași (pentru a verifica corectitudinea calculului rangurilor) Elevul primește un scor de calitate a răspunsului de Elevul primește un scor de calitate a răspunsului de Elevul are cea mai scurtă lungime posibilă a identificatorului (pentru a verifica ordinea corectă) Elevul are cel mai lung identificator posibil Numărul de studenți este de așa natură încât raportul are o dimensiune puțin mai mare decât o pagină (pentru a vedea cazul tipăririi pe altă pagină) Numărul de studenți este astfel încât raportul este pe o singură pagină Raportați condiții la limită (medie, mediană, abatere standard): Valoarea medie este maximă (calitatea răspunsurilor tuturor elevilor este cea mai ridicată) Valoarea medie este (calitatea răspunsurilor tuturor elevilor este ) Abaterea standard este egală cu maximul său (un elev primește un punctaj de , iar celălalt - ) Abaterea standard este (toți elevii primesc aceeași notă) Testele și acoperă, de asemenea, limitele medianei Un alt test util descrie o situație în care există elevi (verifică împărțirea cu la calcularea valorii așteptate), dar este identic cu testul Raportul de verificare oferă următoarele teste de valoare limită: Toți elevii răspund corect la prima întrebare ■ Toți elevii răspund incorect la prima întrebare Toți elevii răspund corect la ultima întrebare Toți elevii răspund greșit la ultima întrebare Numărul de întrebări este astfel încât raportul este puțin mai lung de o pagină Numărul de întrebări este astfel încât raportul este pe o singură pagină Un programator experimentat va fi probabil de acord că multe dintre aceste de teste dezvăluie prezența unor greșeli comune care pot fi făcute în dezvoltarea unui anumit program În plus, majoritatea acestor erori probabil nu ar fi fost detectate dacă s-ar fi folosit o metodă de generare aleatorie a testelor sau o metodă specială de generare a testelor Analiza valorii limită, atunci când este aplicată corect, este una dintre cele mai utile tehnici de proiectare a testelor Cu toate acestea, de multe ori se dovedește a fi ineficient datorită faptului că pare simplu la exterior Cititorul ar trebui să fie conștient de faptul că condițiile de limită pot fi subtile și, prin urmare, dificil de determinat APLICAREA DIAGRAMEI FUNCȚIONALE Unul dintre dezavantajele analizei valorii la limită și ale partiției echivalente este că nu examinează combinațiile de condiții de intrare De exemplu, să presupunem că programul MTEST din secțiunea anterioară eșuează dacă produsul dintre numărul de întrebări și numărul de studenți depășește o anumită limită (cum ar fi cantitatea de memorie) O astfel de eroare nu va fi neapărat detectată prin testarea valorii la limită Testarea combinațiilor de condiții de intrare nu este o sarcină ușoară, deoarece chiar și cu partiția echivalentă construită a condițiilor de intrare, numărul de combinații este de obicei mare astronomic Dacă nu există o modalitate sistematică de a selecta un subset al condițiilor de intrare, atunci, de regulă, este selectat un subset arbitrar, rezultând un test ineficient Metoda diagramelor funcționale sau diagramele relațiilor cauză-efect [ ] ajută la selectarea sistematică a testelor performante Are un efect secundar util, deoarece vă permite să detectați incompletitudinea și ambiguitatea în specificațiile originale O diagramă funcțională este un limbaj formal în care este tradusă o specificație scrisă în limbaj natural O diagramă poate fi asociată unui circuit logic digital (rețea logică combinatorie), dar o notație mai simplă (forma de notație) este folosită pentru a o descrie decât forma obișnuită de notație adoptată în electronică Pentru a înțelege metoda diagramelor funcționale, cunoștințele de electronică nu sunt deloc necesare, dar o înțelegere a logicii booleene (adică operatori logici și, sau și nu) este de dorit Construcția testelor prin această metodă se realizează în mai multe etape Specificația este împărțită în secțiuni „de lucru” Acest lucru se datorează faptului că diagramele funcționale devin greoaie atunci când sunt aplicate la specificații mari De exemplu, atunci când un sistem de partajare a timpului este testat, zona de lucru poate fi specificația unei singure instrucțiuni La testarea unui compilator, fiecare operator individual al unui limbaj de programare poate fi considerat o zonă de lucru Specificația definește cauza și efectul Motivul este o singură precondiție sau o clasă de echivalență a precondiției Consecința este starea ^ de ieșire sau transformarea sistemului (efectul rezidual pe care condiția de intrare îl are asupra stării programului sau sistemului) De exemplu, dacă un mesaj către program are ca rezultat o actualizare a fișierului principal, atunci schimbarea acestuia este transformarea sistemului; un mesaj de confirmare ar fi o condiție de ieșire Cauzele și efectele sunt determinate de citirea secvențială (cuvânt cu cuvânt) a specificației În acest caz, sunt evidențiate cuvinte sau expresii care descriu cauze și efecte Fiecărei cauze și efect i se atribuie un număr separat Este analizat conținutul semantic al specificației, care este transformat într-un grafic boolean care leagă cauze și efecte Aceasta este diagrama funcțională f Diagrama este adnotată cu constrângeri care descriu combinații de cauze și/sau efecte care nu sunt posibile din cauza constrângerilor sintactice sau externe Prin trasarea metodică a stărilor de condiție ale diagramei, aceasta este transformată într-un tabel de decizie cu intrări limitate Fiecare coloană a tabelului de decizie corespunde unui test Coloanele din tabelul de decizie sunt convertite în teste Simbolurile de bază pentru scrierea diagramelor funcționale sunt prezentate în fig Fiecare nod al diagramei poate fi în două stări - sau ; înseamnă neprezent, iar înseamnă prezent Funcția de identitate afirmă că dacă valoarea lui a este , atunci și valoarea lui b este ; în caz contrar, valoarea lui b este Funcția nu afirmă că dacă a este , atunci b este ; în caz contrar, b este Funcția sau afirmă că dacă a, sau b, sau c este I, atunci d este ; în caz contrar, d este Funcția u afirmă că dacă atât a cât și b sunt , atunci c este ; în caz contrar c este Ultimele două funcții permit orice număr de intrări Pentru a ilustra cele de mai sus, luați în considerare o diagramă care afișează specificația: caracterul din coloana trebuie să fie litera „A” sau „B”, iar în coloana trebuie să fie un număr În acest caz, fișierul este actualizat Dacă primul simptom- boul este incorect, atunci se emite mesajul X , iar dacă al doilea caracter este incorect, mesajul X Identitatea nu este Orez Relații logice de bază ale diagramelor funcționale Motivele sunt - simbolul „A” în coloană ke ; - simbolul „B” în coloană ke ; - numărul din coloana , si consecintele - fișierul este în curs de actualizare; - este emis un mesaj X ; - este emis un mesaj X Schema funcțională este prezentată în fig Rețineți că aici este creat un nod intermediar AND Cititorul ar trebui să verifice dacă diagrama reprezintă de fapt specificația dată, dând cauzelor toate valorile posibile și verificând dacă consecințele iau valorile corecte Pentru cititorii familiarizați cu diagramele logice, Fig prezintă circuitul logic echivalent Deși diagrama din fig afișează specificația, conține o combinație imposibilă de cauze - cauzele și nu pot fi setate la în același timp În majoritatea programelor, anumite combinații de motive nu sunt posibile din cauza restricțiilor sintactice sau externe (de exemplu, un simbol nu poate fi „A” și „B” în același timp) În acest caz, sunt utilizate constrângeri logice suplimentare, prezentate în Fig Constrângerea E afirmă că E trebuie să fie adevărată dacă cel puțin una dintre cauze, a sau b, evaluează la (o și & nu pot evalua ambele la ) Constrângerea I afirmă că cel puțin unul dintre a, b sau c trebuie să fie întotdeauna (a, b și c nu pot ia în același timp valoarea ) Restrictia O afirmă că unul și numai unul dintre a sau b trebuie să fie Constrângerea R afirmă că dacă a este , atunci ub trebuie să fie mama sens Orez Exemplu de diagramă funcțională (adică nu este posibil ca a să fie și b să fie ) Adesea este nevoie de restricții pentru consecințe ! Constrângerea M din fig prevede că dacă consecința a are valoarea , atunci consecința b trebuie să ia valoarea După cum se poate observa din exemplul discutat mai sus, este imposibil din punct de vedere fizic ca cauzele și să fie prezente în același timp, dar este posibil Orez Circuit logic echivalent cu schema din fig exclude Include a avea unul dintre ei Prin urmare, ele sunt conectate prin constrângerea E (Fig ) Să ilustrăm utilizarea diaguri traditionale Orez Simboluri de restricție Necesită / X \m Se ascunde Orez Simbol pentru restricție „ascunsă” grame pentru a face teste În acest scop, vom folosi specificația pentru comanda debug într-un sistem interactiv Orez Un exemplu de diagramă funcțională cu constrângerea „exclude” Comanda DISPLAY este utilizată pentru a afișa pe ecran alocarea memoriei Sintaxa comenzii este prezentată în fig Parantezele reprezintă operanzi opționali alternativi Literele mari indică cuvintele cheie ale operanzilor, iar literele precedate de puncte indică valorile operanzilor B SPLRY Adresa - Adresa -EIUP counter bye tj Orez Sintaxa comenzii DISPLAY (adică valorile efective ale operanzilor de înlocuit) Operanzii subliniați corespund valorilor standard (adică, dacă un operand este omis, se presupune valoarea standard) Primul operand (adresa ) specifică adresa primului octet al zonei de memorie al cărei conținut urmează să fie afișat pe ecran Lungimea adresei este specificată de una până la șase cifre hexazecimale ( - , A-F) Dacă primul operand nu este definit, atunci adresa se presupune a fi Adresa trebuie să ia o valoare dintr-o zonă de memorie validă a mașinii Al doilea operand specifică cantitatea de memorie care trebuie mapată Dacă este specificată adresa , atunci oi specifică la rândul său adresa ultimului octet al zonei de memorie care urmează să fie afișată pe ecran Lungimea acestei adrese este de una până la șase cifre hexazecimale Trebuie să fie mai mare sau egală cu adresa de început (adresa ) La fel, adresa trebuie să ia valori din zona de memorie reală a mașinii Dacă END este specificat ca al doilea operand, atunci memoria este mapată până la ultima adresă validă a mașinii Dacă un contor de octeți este specificat ca operand, atunci acesta determină, la rândul său, numărul de octeți de memorie care trebuie mapați (începând Adresa și adresa sunt hexazecimale - Notă ed din octetul cu adresa adresa ) Operandul de numărare de octeți este un număr întreg hexazecimal (între unu până la șase cifre) Suma valorilor operandului numărul de octeți și adresa nu trebuie să depășească dimensiunea reală a memoriei plus unu, iar numărul de octeți trebuie să aibă cel puțin o valoare de Starea memoriei este afișată pe ecranul terminalului ca una sau mai multe linii din următorul format: xxxxxx - cuvânt cuvânt cuvânt cuvânt , unde xxxxxxx este adresa hexazecimală a cuvântului Numărul total de cuvinte (secvențe de patru octeți în care adresa primului octet din cuvânt este un multiplu de patru) este întotdeauna afișat, indiferent de valoarea adresei operandului sau de cantitatea de memorie afișată Toate liniile de ieșire conțin întotdeauna patru cuvinte ( octeți) Primul octet al zonei de memorie mapată se află în primul cuvânt Pot apărea următoarele mesaje de eroare: M SINTAXA COMANDĂ INCORECTĂ M ADRESA CERATĂ MAI MARE M A CERUT O ZONA DE MEMORIE CU O ADRESĂ NEGATIVE SAU ZERO Exemple de comenzi DISPLAY: AFIŞA afișează primele patru cuvinte din memorie (valoarea implicită a adresei de început este , iar valoarea implicită a contorului de octeți este ); DISPLAY F afișează cuvântul care conține octetul cu adresa F și trei cuvinte ulterioare; DISPLAY F - A afișează cuvintele care conțin octeți de la adresele de la ot F la A; DISPLAY F afișează cuvinte care conțin șase octeți începând cu adresa F; DISPLAY FF—END afișează cuvintele care conțin octeți de la adresa FF până la sfârșitul memoriei Primul pas este să analizați cu atenție cificare în vederea identificării cauzelor și efectelor Motivele sunt: Prezența primului operand Adresa operandului conține doar cifre hexazecimale Adresa operandului conține unul până la șase caractere Adresa operandului se află într-o zonă de memorie validă Al doilea operand este END Al doilea operand este adresa Al doilea operand este un numărător de octeți Al doilea operand lipsește Adresa operandului conține doar cifre hexazecimale Adresa operandului conține unul până la șase caractere Adresa operandului se află într-o zonă de memorie validă Adresa operandului este mai mare sau egală cu adresa operandului Operandul contor de octeți conține doar cifre hexazecimale Operandul contor de octeți conține unul până la șase caractere Număr de octeți + dimensiunea memoriei adresa + Număr de octeți ^ Zona de memorie solicitată este atât de mare încât necesită multe linii pe ecran Începutul regiunii nu este aliniat la granița unui cuvânt Fiecare motiv corespunde unui singur număr arbitrar Rețineți că sunt necesare patru motive ( - ) pentru a descrie al doilea operand, deoarece al doilea operand poate lua valorile ) END, ) adresa , ) numărul de octeți, ) poate fi absent și ) valoare nedefinită, adică niciuna dintre cele de mai sus Consecințe: Mesajul M este afișat pe ecran Mesajul M este afișat pe ecran Mesajul M este afișat pe ecran Memoria este afișată pe o linie Afișarea stării memoriei necesită mai multe linii Primul octet al zonei de memorie mapată este aliniat la o limită de cuvânt Primul octet al zonei de memorie mapată nu este aliniat cu cuvinte Al doilea pas este dezvoltarea unei diagrame funcționale Cauza nodurilor sunt listate vertical la marginea stângă a paginii; nodurile consecintelor sunt colectate vertical la marginea sa dreapta Conținutul semantic al specificației este analizat cu atenție pentru a lega cauze și efecte (adică, pentru a arăta în ce condiții are loc efectul) Pe fig prezintă versiunea inițială a diagramei Nodul intermediar reprezintă un prim operand corect din punct de vedere sintactic, nodul reprezintă un al doilea operand corect din punct de vedere sintactic, iar nodul reprezintă o instrucţiune corectă din punct de vedere sintactic Dacă valoarea nodului este , atunci consecința (mesaj de eroare) lipsește Dacă valoarea nodului este , atunci corolarul este valabil Pe fig prezintă o diagramă funcțională completă Cititorul ar trebui să verifice această diagramă cu atenție pentru a se asigura că reprezintă cu exactitate specificația Orez oval Versiunea inițială a funcției-dpagramă a comenzii DISPLAY Dacă diagrama din fig este folosit direct pentru a construi teste, apoi crearea multor dintre ele va fi de fapt imposibilă Acest lucru se datorează faptului că anumite combinații de cauze nu pot apărea din cauza restricțiilor sintactice De exemplu, cauzele și nu pot fi prezente fără cauză Orez Diagrama funcțională completă fără restricții suntem Cauza nu poate fi prezentă dacă nu există cauzele și În fig Figura prezintă diagrama finală cu toate restricțiile suplimentare Notă • că poate fi prezentă doar una dintre cauzele , , sau Alte restricții de cauză sunt condițiile de tip cerute Cauza (multe linii pe ecran) și cauza (fără al doilea operand) sunt legate prin not; cauza poate fi prezentă numai în absența Influența cauzei Din nou, cititorul trebuie să examineze cu atenție orice restricții impuse condițiilor Al treilea pas este generarea unui tabel de decizie cu intrări limitate Pentru cititorii familiarizați cu tabelele de decizie, cauzele sunt condiții și efectele sunt sunt actiuni Procedura de generare este următoarea: Selectați o consecință care ar trebui să fie în starea Găsiți toate combinațiile de cauze (supuse restricțiilor) care vor seta acest efect la , urmărind acest efect prin diagramă Construiți o coloană în tabelul de decizie pentru fiecare combinație de motive Pentru fiecare combinație de cauze, determinați stările tuturor celorlalte efecte și plasați-le în coloana corespunzătoare a tabelului de decizie Există trei lucruri de care trebuie să țineți cont atunci când faceți acest pas: Dacă calea inversă este așezată prin nod sau, a cărei ieșire trebuie să ia valoarea , atunci mai mult de o intrare în acest nod nu trebuie setată la în același timp Această constrângere privind setarea valorilor de intrare se numește sensibilitate a căii Scopul acestei reguli este de a evita ratarea anumitor erori deoarece o cauză este mascata de alta Dacă o urmă inversă este direcționată printr-un nod u a cărui ieșire trebuie să ia valoarea , atunci toate combinațiile de intrări care aduc ieșirea la trebuie în cele din urmă enumerate Cu toate acestea, atunci când examinăm o situație în care o intrare este și una sau mai multe alte intrări sunt , nu este necesar să enumerați toate condițiile în care intrările rămase pot fi Dacă următorul invers este așezat prin nod și, a cărui ieșire trebuie să ia valoarea , atunci este necesar să se specifice o singură condiție, conform căreia toate intrările sunt zero (Când un nod se află în mijlocul graficului, iar intrările sale provin de la alte noduri intermediare, poate exista un număr extrem de mare de situații în care toate intrările sale sunt ) Aceste prevederi sunt explicate pe scurt în Fig Orez este dat ca exemplu de diagramă funcțională Să fie necesar să se stabilească condițiile de intrare în așa fel încât să se stabilească starea de ieșire la Conform Propoziției , ar trebui luat în considerare un singur caz când nodurile și sunt zerouri Prin poziţia , pentru starea în care nodul ia valoarea , iar nodul valoarea , ar trebui să se ia în considerare doar un caz când nodul ia valoarea (fără a enumera alte cazuri posibile când nodul poate lua valoarea ) Stat Situatie Orez Pozițiile utilizate la așezarea urmei din spate prin diagramă: Dacă X trebuie să fie egal atunci nu trebuie luată în considerare situația în care a=t>= (poziția ) Dacă X trebuie să fie egal cu , atunci enumerați toate situațiile în care a = b - Dacă X trebuie să fie egal cu , atunci enumerați toate situațiile în care a = b = c - Dacă X trebuie să fie egal cu , atunci luați în considerare o singură situație, unde a - b - c - (poziția ) Pentru stările a, b și c , , , OH, și HO, luați în considerare doar una, oricare dintre aceste situații (poziția ) ) În mod similar, pentru o stare în care nodul este setat la și nodul este setat la , ar trebui luat în considerare doar un caz în care nodul este setat la (deși acesta este singurul caz în acest exemplu) Conform clauzei , dacă nodul trebuie să fie setat la starea , nu se recomandă setarea nodurilor și la starea în același timp Astfel, sunt posibile cinci stări ale nodurilor , de exemplu, valorile Orez Un exemplu de diagramă funcțională pentru a ilustra trasarea înapoi ■ ( = , = ) ( = , = ) ( = , = ) ( = , = ) ( = , = ) mai degrabă decât „ ”, ceea ce duce la o stare de ieșire de La prima vedere, aceste prevederi pot părea părtinitoare, dar au un scop important: reducerea combinatoriei diagramei Utilizarea lor permite evitarea situațiilor care duc la teste ineficiente Dacă nu excludem testele cu performanță scăzută, atunci numărul total de teste generate dintr-o diagramă funcțională mare este astronomic Dacă, chiar și fără ele, numărul de teste este încă mare, atunci este selectat un subset de teste, dar nu este garantat că testele cu performanță scăzută vor fi excluse Prin urmare, cel mai bine este să le excludeți în procesul de analiză a diagramei Să transformăm diagrama funcțională prezentată în Fig , la tabelul de decizie Alegem ca prim corolar corolarul Corolarul apare dacă nodul ia valoarea Valoarea nodului este dacă valoarea nodurilor și este , , , sau , și se aplică afirmațiile și transformarea este un proces laborios, dar este posibil să se urmărească de la efecte la cauze, ținând cont de limitările cauzelor și găsirea combinațiilor dintre acestea din urmă care conduc la efect Tabelul de decizie rezultat, cu condiția ca Corolarul să fie valabil, este prezentat în Fig (coloanele - ) Coloanele (testele) - reprezintă condiții în care nodul este și nodul este Coloanele - reprezintă condiții în care nodul este și nodul este O singură situație este definită folosind clauza (coloana ) din cele posibile atunci când nodurile și sunt Spațiile reprezintă situații „indiferente” (adică starea cauzei este imaterială) sau indică faptul că starea cauzei este evidentă datorită stărilor altor cauze dependente (de exemplu, pt coloana se știe că cauzele , și trebuie să ia valori , deoarece sunt legate de constrângerea „unul și singurul” la cauza ) Coloanele - reprezintă situaţii în care Corolarul este valabil, iar coloanele și arată situații în care Corolarul este valabil arată restul tabelului de decizie Ultimul pas este convertirea tabelului de decizie în de teste Un set de de teste g S L tl K X k B optsprezece Orez Prima jumătate a tabelului de decizie rezultat prezentat mai jos Cifrele de lângă fiecare test indică consecințele care se așteaptă să aibă loc aici Să presupunem că ultima adresă de memorie folosită! mașinile au FFF D D Orez A doua jumătate a tabelului de decizie rezultat DISPLAY AF — ( ) DISPLAY ZX — ( ) DISPLAY NNNNNNN— ( ) DISPLAY ( ) DISPLAY - ( ) DISPLAY - X ( ) DISPLAY —ABCDEFGHI ( ) DISPLAY ( ) DISPLAY S ( ) AFIȘARE ®®$®$®$ ( ) DISPLAY —M ( ) DISPLAY FF - ( ) DISPLAY FFF ( ) DISPLAY —END ( ) DISPLAY - ( ) DISPLAY AA—A ( ) DISPLAY ( ) DISPLAY FF -END ( , ) DISPLAY ( , V DISPLAY — ( , )- DISPLAY LA ( , ) AFIȘARE - sfârșit ( , ) DISPLAY ( , ) DISPLAY - F ( , ) DISPLAY E ( , ) DISPLAY FF - END ( , ) DISPLAY ( , ) DISPLAY AO—A ( , ) DISPLAY , ( , ) DISPLAY - END ( , ) DISPLAY - ( , ) DISPLAY FF ( , ) AFIȘARE - sfârșit ( , ) DISPLAY - ( , ) DISPLAY ( ) DISPLAY - END ( , ) DISPLAY - ( , ) DISPLAY ( ) Rețineți că atunci când două sau mai multe teste diferite corespund aceluiași set de cauze, ar trebui să încercați să alegeți valori diferite ale cauzelor pentru a îmbunătăți performanța testelor chiar și ușor Rețineți, de asemenea, că, din cauza dimensiunii limitate a memoriei, Testul este irealizabil („folosirea acestuia va avea ca rezultat Corolarul în loc de , așa cum este menționat în Testul ) Prin urmare, doar de teste sunt realizabile Remarci Utilizarea diagramelor funcționale este o metodă sistematică de generare a testelor reprezentând combinații de condiții Alternativa este selecția ad-hoc a combinațiilor, dar există posibilitatea de a pierde multe dintre testele „interesante” identificate de diagrama funcțională Când se utilizează diagrame funcționale, este necesară traducerea specificației într-o rețea logică booleană Prin urmare, această metodă deschide perspective pentru aplicarea sa și posibilități suplimentare pentru specificații Într-adevăr, dezvoltarea diagramelor funcționale este o modalitate bună de a detecta incompletitudinea și ambiguitatea în specificațiile originale De exemplu, cititorul poate observa că procesul propus dezvăluie o caracter incomplet în specificația comenzii DISPLAY Specificația afirmă că toate ieșirile Noile rânduri conțin patru cuvinte Acest lucru nu este adevărat în toate cazurile; de exemplu, pentru testele și acest lucru nu este adevărat, deoarece pentru ele adresa de început a memoriei mapate diferă de adresa de final a memoriei mașinii cu mai puțin de octeți Metoda diagramei funcționale vă permite să construiți un set de teste utile, dar aplicarea acestuia de obicei nu oferă construcția tuturor testelor utile care pot fi definite Deci, în exemplul nostru, nu am spus nimic despre verificarea identității valorilor datelor afișate pe ecranul terminalului cu datele din memorie și despre stabilirea cazului în care programul poate afișa orice valoare posibilă stocată în celula de memorie pe ecran În plus, diagrama funcțională nu explorează în mod adecvat condițiile la limită Desigur, în procesul de lucru cu diagrame funcționale, puteți încerca să acoperiți condițiile limită De exemplu, în loc să definiți un singur motiv adresa adresa pot fi identificate două motive adresa - adresa adresa > adresa Cu toate acestea, în acest caz, graficul devine mult mai complicat, iar numărul de teste devine extrem de mare Prin urmare, este mai bine să separați analiza valorilor limită de metoda diagramelor funcționale De exemplu, pentru specificarea unei comenzi DISPLAY, pot fi definite următoarele condiții limită: Adresa are o cifră Adresa are șase cifre Adresa are șapte cifre Adresa = Adresa / = FFF Adresa / = Adresa are o cifră Adresa are șase cifre Adresa are șapte cifre Adresa = Adresa = FFF Adresa = Adresa =adresa Adresa =adresa + Adresa =adresa - Număr de octeți lung de o cifră Contor de octeți lungime de șase cifre Contor de octeți lung de șapte cifre Număr de octeți - Adresa + contor octet = Adresă + număr de octeți - Afișați șaisprezece octeți (o linie) Afișare de șaptesprezece octeți (două linii) Acest lucru nu înseamnă că ar trebui să scrieți de teste ( + ) Deoarece diagrama funcțională oferă doar îndrumări în alegerea anumitor valori ale operanzilor, condițiile la limită pot fi incluse în testele derivate din aceasta În exemplul nostru, prin rescrierea unora dintre cele de teste originale, putem acoperi toate cele de condiții la limită fără teste suplimentare Astfel, obținem o suită de teste mică, dar convingătoare, care ne satisface obiectivele Rețineți că metoda diagramelor funcționale este în concordanță cu unele dintre principiile de testare prezentate în Cap Partea sa integrantă este definirea rezultatului așteptat al fiecărui test (toate coloanele din tabelul de decizie indică consecințele așteptate) De asemenea, rețineți că această metodă ajută la identificarea efectelor secundare eronate De exemplu, coloana (testul) precizează că trebuie să fie prezent corolarul Î și că trebuie să lipsească corolarele - Cel mai dificil lucru în implementarea metodei este transformarea diagramei într-un tabel de decizie Această transformare este un proces algoritmic Prin urmare, poate fi automatizat prin scrierea unui program adecvat IBM are o serie de astfel de programe, dar nu le furnizează Un alt exemplu de aplicare a diagramelor funcționale poate fi găsit în [ ] PREZUMEREA DE EROARE S-a observat că unii oameni, în virtutea calităților lor, se dovedesc a fi excelenți testeri de programe Ei au capacitatea de a „depista” erorile fără a recurge la vreo metodologie de testare (cum ar fi analiza valorii la limită sau utilizarea diagramelor funcționale) Acest lucru se explică prin faptul că o persoană care are experiență, adesea subconștient aplică o tehnică de proiectare a testelor numită ghicirea erorilor Având în vedere un anumit program, acesta își asumă în mod intuitiv tipurile probabile de erori și apoi dezvoltă teste pentru a le detecta Procedura pentru metoda de estimare a erorilor este dificil de descris deoarece este în mare parte intuitivă Ideea sa principală este să enumere posibile erori sau situații în care acestea pot apărea într-o listă, iar apoi să scrie teste pe baza acestei liste De exemplu, o astfel de situație apare atunci când valoarea la intrarea și la ieșirea programului Prin urmare, este posibil să se construiască teste pentru care anumite intrări sunt nule și pentru care anumite ieșiri sunt setate la Când numărul de intrări sau ieșiri este variabil (de exemplu, numărul de înregistrări de intrare de căutat într-o căutare în listă) , erorile sunt posibile în situații precum „niciunul” și „unu” (de exemplu, o listă goală, o listă care conține o singură intrare căutată) O altă idee este de a defini teste legate de ipotezele pe care un programator le-ar putea face în timp ce citește specificația (adică lucruri care au fost omise din specificație fie din întâmplare, fie pentru că autorul specificației a crezut că sunt evidente) Deoarece această procedură nu poate fi definită în mod clar, cel mai bun mod de a discuta semnificația ipotezei de eroare este să se uite la exemple Dacă luăm în considerare testarea unei rutine de sortare ca exemplu, atunci trebuie să investigăm următoarele situații: Lista sortabilă este goală Lista de sortat conține o singură valoare Toate intrările din lista sortată au aceeași valoare Lista este deja sortată Cu alte cuvinte, este necesar să se enumere acele cazuri speciale care ar putea să nu fie luate în considerare la proiectarea unui program Dacă exemplul este de a testa o rutină de căutare binară, atunci pot fi testate următoarele situații: ) există o singură intrare în tabel care este căutată; marimea - tabelele sunt o putere de doi (de exemplu, ); ) dimensiunea tabelului este mai mică sau mai mare decât o putere de doi (de exemplu, , ) Luați în considerare programul MTEST prezentat în secțiunea privind analiza valorii la limită Când testați acest program utilizând metoda ghicirii erorilor, este util să luați în considerare următoarele teste suplimentare: patru cinci Programul permite „spațiu” ca răspuns? O înregistrare de tip (răspuns) apare într-un set de înregistrări de tip (student) O intrare fără sau în ultima coloană nu apare ca intrare inițială (nume) Doi elevi au același nume sau număr Deoarece mediana este calculată diferit în funcție de numărul de elemente par sau impar, este necesar să se testeze programul atât pentru un număr par, cât și pentru un număr impar de studenți Câmpul pentru numărul de întrebări are o valoare negativă Pentru comanda DISPLAY din secțiunea anterioară, merită să luați în considerare următoarele teste ale metodei de estimare a erorilor: DISPLAY —(al doilea operand incomplet) DISPLAY (al doilea operand incomplet) DISPLAY - A (valoarea operandului prea mare) DISPLAY - FF (zerouri în stânga) ■STRATEGIE Metodologiile de proiectare a testelor discutate în acest capitol pot fi combinate într-o strategie comună Motivul combinării lor devine acum evident: fiecare metodă oferă un set specific de teste utilizabile, dar niciuna dintre ele singur nu poate produce un set complet de teste Strategie acceptabilă constă din următoarele: Dacă specificația conține combinații de condiții de intrare, atunci se recomandă să începeți cu aplicarea metodei diagramelor funcționale În orice caz, trebuie utilizată analiza valorii la limită Amintiți-vă că această metodă include analiza valorilor limită ale variabilelor de intrare și de ieșire Analiza valorii limită oferă un set de condiții de testare suplimentare, dar așa cum s-a menționat în secțiunea privind diagramele funcționale, multe dintre ele (dacă nu toate) pot fi incluse în testele metodei diagramei funcționale Determinați clasele de echivalență corecte și incorecte pentru datele de intrare și ieșire și completați, dacă este necesar, testele construite în pașii anteriori Pentru teste suplimentare, se recomandă utilizarea metodei de estimare a erorilor Verificați logica programului pe setul de teste primit Pentru a face acest lucru, trebuie să utilizați criteriul de acoperire a deciziei, acoperirea condiției, acoperirea deciziei/condiții sau acoperirea condiției combinatorii (cel din urmă criteriu este mai complet) Dacă necesitatea îndeplinirii criteriului de acoperire duce la construirea unor teste care nu se regăsesc printre cele construite în cei patru pași anteriori și dacă acest criteriu nu este irealizabil (adică anumite combinații de condiții nu pot fi create datorită naturii program), atunci setul deja construit de teste ar trebui completat cu teste, al căror număr este suficient pentru a satisface criteriul de acoperire Această strategie, din nou, nu garantează că toate erorile vor fi găsite, dar oferă un compromis acceptabil Implementarea unei astfel de strategii este foarte laborioasă, dar nimeni nu a susținut vreodată că testarea unui program este o sarcină ușoară LITERATURĂ Grafice cauză-efect Elmendorf WR în testarea funcțională TR- , IBM Systerns Developer Division, Poughkeepsie, NY, M ers GJ Software Reliability: Principii și practici New York, Wiley-Interscience, Traducere rusă: Myers G Software Reliability M , Mir, CAPITOLUL TESTARE MODULE Având în vedere problemele de testare, până acum am ignorat în mare măsură factori precum organizarea procedurii de testare și dimensiunea programelor testate Cu toate acestea, trecerea la programe mari ( de instrucțiuni sau mai mult) necesită modalități speciale de structurare a procesului de testare În acest capitol, ne vom uita la pasul inițial de structurare – testarea unitară Următorii pași sunt discutați în Cap Testarea unitară (sau bloc) este procesul de testare a subrutinelor individuale sau a procedurilor programului Acest lucru implică faptul că înainte de a începe să testați programul în ansamblu, ar trebui să testați modulele mici individuale care alcătuiesc acest program Această abordare este motivată de trei motive În primul rând, devine posibil să se controleze combinatoria testării, deoarece inițial atenția se concentrează asupra modulelor de program mici În al doilea rând, este facilitată sarcina de depanare a programului, adică găsirea locului erorii și corectarea textului programului În cele din urmă, în al treilea rând, paralelismul este permis, ceea ce vă permite să testați simultan mai multe module Scopul testării modulelor este de a compara funcțiile implementate de un modul cu specificațiile funcțiilor sau ale interfeței sale Subliniem că același scop este propus în formularea generală a problemei de testare, iar problema nu este de a stabili corespondența modulului cu specificația, ci de a arăta contradicția dintre ele Procesul de testare unitară este luat în considerare în trei aspecte: modalități de construire a suitelor de testare, ordinea în care sunt testate unitățile ■ sunt colectate și asamblate într-un program și câteva recomandări practice pentru implementarea testării PROIECTARE DE TESTARE La proiectarea testelor pentru modulele de testare, trebuie să fie disponibile două surse de informații: specificația modulului și textul acestuia Specificația conține de obicei o descriere a parametrilor de intrare și de ieșire ai modulului și a funcțiilor acestuia Testarea unitară se concentrează în principal pe Codul Numele postului Departamentul Salariu Masa angajaților Sumă Departamentul de vanzari birou Orez Tabel de introducere a modulelor BONUS principiul cutiei albe Acest lucru se datorează în primul rând faptului că principiul cutiei albe este mai dificil de implementat atunci când se trece ulterior la testarea unităților mai mari, cum ar fi programele în ansamblu În plus, etapele ulterioare ale testării sunt concentrate pe detectarea erorilor de diferite tipuri, adică erori care nu sunt neapărat legate de logica programului, dar care apar, de exemplu, din cauza programului care nu îndeplinește cerințele utilizatorului Prin urmare, procedura de creare a unui set de teste pentru testarea modulelor este următoarea: logica unui modul separat este analizată cu ajutorul unuia sau nu câte metode de cutie albă și apoi acest set de acelea - stov este utilizat la testarea cu metode cutie neagră conform specificațiilor modulului Să ilustrăm utilizarea metodelor de construcție a testelor descrise în Cap , la testarea modulelor Să presupunem că trebuie să testăm modulul BONUS Funcția acestui modul este de a crește cu USD mărimea TESTAREA MODULULUI BONUS: PROCEDURĂ (ERRCODEJ, DEPT? AB, ESIZE, DSIZE, ERRCODEJ ; DECLARE EMPTAB (*), HAHECHAR( ) , COD CHAR ( ) , DFPTCHAR( ) , SALARIU FIX DEC IMAL ( , ; DECLARE DEPTTAB (*) DEPTCHAR( ) , VÂNZĂRI FIX DEC IHA L ( , ) ; DECLARE (DIMENSIUNE,DIMENSIUNE) BIKARY FIX; DECLARE ERRCODE FIXED DECIMAL(I): DECLARE KAXSALES FIXED DECI HAL (R ) INIT(O); VÂNZĂRI ÎN DEPTTAB*/ DECLARE (I,J,K) BINARI FIX; /•CONTARE»/ DECLARE BITUL GĂSIT ( ) ; /-TREI IF ELTCLBLE DEPT ARE ANGAJATI*/ DECLARE SINC FIXED DECIMAL( r ) INTT ( OD) ; /'STANDARD INCREMENT•/ DECLARE LIXC FIXED DECIMAL( , ) INIT ( ) : /•LOU R INCREMENT*/ DECLARE LSALARY FIXED DECIMAL( , ) INIT ( D DO) ; /•SALARY BO'JNDARY*/ DECLARE MGR CHAR( ) INIT ('"'); FRRCODE^O; ІГ(SIZE = MA XS ALES) TREN fi A XSA LES= VÂNZĂRI (I i ; sfârșit; DO J = LA DIMENSIUNEA; DACĂ (VÂNZĂRI(J)=MAX ALES) /«ELIGIBIL DEPA GM£N!•/ ATUNCI FĂ; FOHND='D'B; DO K = PENTRU DIMENSIUNEA; IF(EMPTAB DEPT(K)-DEPTTAB DEPT(â)) (j TREN DO; FCUND=' 'B; b DACĂ (SALARUL (K) >=LSALARY) | (COD(K)=KG ) TREN SALARIU(K)=SALASY(K) ♦LINC; ELSE SALARY(K) =SALARY(K) *SINC; Sfârșitul; D END; IF(-FO'JND) TH-N ERRC DE = ; SFÂRȘIT; EHD; EHD; Sfârșitul; Orez Modul BONUS salariile tuturor angajaților departamentului sau departamentelor care asigurau vânzarea mărfurilor pentru cea mai mare sumă Totuși, pentru angajații al căror salariu depășește USD și pentru administratori, indemnizația este de USD Pe fig prezintă tabele cu valorile de intrare Pe baza rezultatelor lucrării, modulul generează un cod de eroare Dacă nu există erori, atunci codul de eroare este Dacă nu există valori de intrare în ambele tabele, atunci codul de eroare este Dacă lista de angajați ai unui departament este goală, atunci va fi un cod de eroare de generate Pe fig arată textul modulului Parametrii de intrare ESIZE și DSIZE conțin numerele de intrări din tabelul de angajați și, respectiv, tabelul de departamente Modulul este scris în PL/ , dar discuția care urmează este independentă de limbajul de programare ales; aceeași tehnologie poate fi folosită pentru programele scrise în diferite limbi Logica modulului este destul de simplă și ar trebui să fie de înțeles pentru cititorii care nu sunt familiarizați cu ■PL/ Indiferent de metoda de acoperire logică utilizată, primul pas este listarea tuturor deciziilor din program Este recomandabil să analizați toate instrucțiunile IF și DO Analizând textul programului, puteți observa că instrucțiunile DO sunt simple iterații, în care valoarea finală a parametrului buclei este mai mare sau egală cu valoarea inițială (aceasta înseamnă că fiecare buclă este executată cel puțin o dată), și singura modalitatea de a ieși din buclă este prin operatorul DO Prin urmare, declarațiile DO nu necesită o atenție specială, deoarece orice test care are ca rezultat o buclă DO se va ramifica în ambele direcții (adică, intrarea și ieșirea din buclă) Din acest motiv, trebuie analizate următoarele afirmații: IF(EIZE =VÂNZĂRI MAX ) IF(VÂNZĂRI(J)=VÂNZĂRI MAX ) IF(EMPTĂB DEPT(K)=DEPTTAB DEPT(J)) DACĂ(SALARIRE(K)>=LSALARY) | (COD(K)=MGR) DACĂ( ~ GĂSIT) Numărul de soluții este mic, astfel încât este probabil să fie aleasă acoperirea multor condiții, dar toate criteriile de acoperire logică (cu excepția acoperirii declarațiilor, care nu este practică) ar trebui testate pentru a lua în considerare performanța lor Pentru a satisface criteriul de acoperire a deciziei este necesară construirea unor teste care să conducă la executarea fiecăreia dintre cele șase instrucțiuni în ambele sensuri Situațiile de intrare necesare pentru aceasta sunt prezentate în Tabelul Sunt situații care patru* Tabelul Situații corespunzătoare rezultatelor deciziei Decizie Rezultat adevărat Rezultat fals ESIZE sau DSIZE ==: ESIZE și DSIZE > Apare cel puțin o dată Comanda în DEPTTAB este de așa natură încât departamentul cu un nivel de vânzări mai scăzut urmează departamentul cu un nivel de vânzări mai ridicat în lista de departamente Se întâmplă cel puțin o dată Toate departamentele au niveluri de vânzări diferite Există un angajat în departamentul relevant Există un angajat care nu este înregistrat în departamentul relevant Angajat eligibil - manager fie câștigă LSALARY sau mai mult Angajat eligibil - non-manager și câștigă mai puțin de LSALARY Departamentul corespondent nu are angajați Departamentul corespondent are cel puțin un angajat Test intrare Ieșire estimată ESIZE=O Valorile tuturor celorlalte variabile de intrare sunt arbitrare ERRCOPE= ESIZE HSIZE EMPTRB și BEPTTRB nu se modifică ERCDDE= ESIZE DSIZE și IERTTDW nu se modifică EMRTYAV Jones E D , Omit E B , Larin E B , ES ZE=OSIZE= EMPTRB OEPTTRB Jones E Bh? , , Smith E D , , Lorin E D , , Orez Teste care satisfac criteriul de acoperire a deciziei trebuie verificat cu teste, deoarece vor avea loc întotdeauna două direcții de ramificație Rețineți că atunci când construiți tabelul direcțiile de ieșire din declarațiile de decizie ar trebui urmărite în logica programului; aceasta va face posibilă estimarea condiţiilor de intrare necesare De exemplu, decizia nu este îndeplinită de niciunul dintre salariații întâlniți în condiții, ci doar de un angajat al departamentului corespunzător Zece situații de interes pentru noi din Tabel , luni- o sută poate fi verificată folosind cele două teste prezentate în Fig Fiecare test, așa cum este descris în cap include valorile așteptate ale cantităților de ieșire Evident, deși testele îndeplinesc criteriul de acoperire a deciziei, în modul pot rămâne multe tipuri de erori pe care nu le detectează De exemplu, aceste teste nu analizează situația când codul de eroare este , angajatul este manager sau tabelul de departament (DSIZE^O) este gol Dacă utilizați metoda de acoperire a stării, puteți obține un test mai acceptabil Această metodă presupune că testele trebuie să aibă ca rezultat ambele rezultate ale fiecărei condiții din declarația de decizie În tabel prezintă condiţiile cerute Tabelul Situații corespunzătoare ieșirilor de condiție Soluție Condiții Valoare adevărată de ieșire Valoare falsă de ieșire ESIZE^O ESIZEsCO ESIZE> DSIZEsiO DSIZEsCO DSIZE> VANZĂRI(I) s MAXSALES Se întâmplă cel puțin o dată VÂNZĂRI(J) = =VÂNZĂRI MAX Se întâmplă cel puțin o dată Toate departamentele au niveluri de vânzări diferite EMPTAB DEPT(K) == DEPTTAB DEPT(J) Există un angajat în acest departament Există un angajat care nu este înregistrat în departamentul corespunzător SALARIU(K)^ LSALARY Acest angajat are un salariu de LSALARY sau mai mult Acest angajat are un salariu mai mic de LSALARY CODE(K) = =MGR Acest angajat este manager Acest angajat nu este manager „] GĂSIT Acest departament nu are angajați Acest departament are cel puțin un angajat situațiile noastre de intrare și rezultatele lor de ieșire corespunzătoare Pentru orice condiție, există două situații de intrare și două de ieșire de luat în considerare, așa că testele ar trebui să verifice situații în total Și din nou acestea Tutațiile pot fi verificate prin două teste, care sunt prezentate în Fig Pentru ilustrare în fig Tabelul enumeră testele care satisfac metoda de acoperire a condiţiei deoarece ■ conduc la executarea tuturor rezultatelor de ieşire indicate în tabelul Cu toate acestea, aceste teste sunt probabil Test Intrare Ieșire estimată ESIZE-BSIZE=O Valorile tuturor celorlalte variabile de intrare sunt arbitrare ERRCOPE= ESIZE, DSIZE, EMPTRB și DEPTtrb nu se modifică ESIZE=DSIZE= EMRTJin DEPTTRE John E D , DZ , Smith E D , D , Lauryn M DZ? , DS , ERRCODE- ESIZE, DSIZE și DEPTTfiB nu se modifică EMPTRB Jones E DZ , Smith E D , Lorin M D Orez Teste care îndeplinesc criteriile de acoperire a stării mai mult decât testele din fig satisfacerea criteriului de acoperire a soluției Ideea este că ele nu determină executarea fiecărei instrucțiuni; instrucțiunea nu este niciodată executată Performanța lor nu este mai mare decât cea a testelor din Fig Aici este imposibilă situația de ieșire ERRCODE = Dacă, de exemplu, introducerea condiției (ESIZE = )&(DSIZE = ) în instrucțiunea este eronată, atunci această eroare nu va fi detectată Desigur, această problemă poate fi rezolvată prin utilizarea unor suite de teste suplimentare, dar rămâne faptul că testele prezentate în Fig satisface criteriul de acoperire a condiției Folosind criteriul de acoperire a condiției, este posibil să se demonstreze deficiențele setului de teste din Fig Să construim teste care să asigure că fiecare ieșire din toate condițiile și toate soluțiile este executată cel puțin o dată Acest lucru poate fi realizat făcându-l pe Jones managerul testului și pe Lauryn ca non-manager Ca urmare, ambele ramuri ale deciziei și declarației vor fi executate Cu toate acestea, acest set de testare nu este în esență mai bun decât setul de testare din Fig Dacă compilatorul utilizat nu mai evaluează expresia, sau imediat ce una dintre declarații este evaluată la adevărat, atunci rezultatul expresiei CODE (K) = MGR din instrucțiune pe nu va evalua niciodată drept adevărat Prin urmare, dacă această expresie nu este codificată corect, atunci această eroare nu va fi detectată de suita de teste Ultimul lucru pe care îl studiem este criteriul de acoperire combinatorie a condițiilor Acest criteriu necesită ca setul corespunzător de teste să conducă la executarea tuturor combinațiilor posibile de condiții în fiecare soluție Test Intrare Mișcarea intenționată ESIZE= BSIZE^D Valoarea tuturor celorlalte variabile de intrare este arbitrară ERRCOBE= ESIZE BSI E EMPTfiB și BEPTTflB nu se modifică ESIZE-O BS ZE>O Valorile tuturor celorlalte variabile de intrare sunt arbitrare ESIZE >О VS ZE = D Valoarea tuturor celorlalte variabile de intrare este arbitrară ES ZE= BSIZE- EMRTOV BERTTOV Jones M B , BZ , Warne M B LA D , Lorin E B , D , Jucărie E B , CU , Smith E B , Apoi Apoi EROARE= ESIZE, BS ZE și BERTT nu sunt modificate EMPTRB JONES m HF , Warne m V W Lorin E B^ W , Soi E £ B Smith E vzg , patru Orez Teste care satisfac criteriile pentru acoperirea combinatorie a afecțiunilor Vom folosi să luăm în considerare tabelul Oricare dintre soluțiile , , și are două combinații de condiții fiecare, iar oricare dintre soluțiile și are patru combinații fiecare Conform metodologiei utilizate pentru construirea testelor, trebuie să alegeți mai întâi testul care acoperă numărul maxim de combinații, apoi testul care acoperă numărul maxim de combinații dintre cele rămase și așa mai departe Figura prezintă o suită de teste care satisface criteriul acoperirii condiției combinatorii Acest set este mai de înțeles decât precedentele și ni se pare că tocmai asta ar fi trebuit ales de la bun început Este important de menționat că modulul BONUS poate conține un număr semnificativ de erori care nu pot fi detectate nici măcar printr-un test care îndeplinește criteriul acoperirii condiției combinatorii De exemplu, nici un test nu poate reproduce situația în care valoarea de ieșire ERRCODE este returnată cu o valoare zero Astfel, dacă instrucțiunea este omisă, eroarea nu va fi detectată De asemenea, nu va fi detectată o eroare dacă constanta LSALARY este setată la S la inițializare sau dacă declarația spune SALARY (K) > LSALARY în loc de SALARY (K) ^LSALARY De regulă, erorile umane (de exemplu, ultima intrare în DEPTTAB sau EMPTAB a fost făcută incorect) pot fi descoperite doar întâmplător Din cele de mai sus rezultă că, în primul rând, criteriul de acoperire combinatorie a condițiilor depășește toate celelalte criterii și, în al doilea rând, niciunul dintre criteriile de acoperire logică nu poate fi utilizat ca singurul mijloc pe baza căruia sunt construite testele de module Prin urmare, este necesar să faceți următorul pas și să combinați testele prezentate în Fig , cu un set de teste cutie neagră În acest scop, luați în considerare specificația interfeței modulului BONUS de mai jos BONUS este un modul scris în PL/ , primește cinci parametri, denumirile lor simbolice sunt EMPTAB, DEPTTAB, ESIZE, DSIZE, ERRCODE; aceste opțiuni au următoarele atribute: DECLARE EMPTAB (*), /*intrare și ieșire*/ PERSONAJ NUME ( ), COD CARACTER ( ), PERSONAJ DEPARTAMENT ( ), SALARIU FIX DECIMAL( , ); DECLARE DEPTTAB (*), /*input*/ PERSONAJ DEPARTAMENT ( ), VÂNZĂRI FIX DECIMAL ( , ); DECLARE (DIMENSIUNE, DSIZE) BINAR FIX; /*intrare*/ DECLARE ERRCODE FIXED DECIMAL ( ): /*input*/ Argumentele transmise de modul au atributele enumerate mai sus în specificație ESIZE și DSIZE specifică numărul de valori de intrare în EMPTAB și, respectiv, DEPTTAB Ordinea valorilor de intrare în EMPTAB și DEPTTAB nu contează Funcția modulului este de a crește salariul (EMPTAB, SALARIU) angajatului departamentului sau departamentelor cu cea mai mare cantitate de vânzări (DEPTTAB VANZĂRI) Dacă un angajat primește un salariu de de dolari și mai mult, sau dacă este manager (EMPTAB CODE="M"), atunci creșterea salariului este de USD; în toate celelalte cazuri - de dolari Creșterea salarială se înregistrează în câmpul EMPTAB SALARIU Dacă ESIZE și DSIZE sunt mai mici decât zero, este generat un ERRCODE de și nu se întreprinde nicio altă acțiune În toate celelalte situații, funcțiile modulului sunt complet executate Cu toate acestea, dacă departamentul având valoarea maximă a vânzărilor, numărul de angajați este zero, apoi variabilei ERRCODE i se atribuie o valoare egală cu ; în toate celelalte cazuri, valoarea este Această specificație nu poate fi utilizată pentru a construi diagrame funcționale (nu conține un set explicit de condiții de intrare, a căror combinație trebuie investigată), prin urmare, se recomandă metoda de analiză a valorii la limită Sunt definite următoarele valori limită de intrare: EMRTAB are o valoare de intrare EMPTAB are numărul maxim de valori de intrare ( ) EMPTÂB are valori de intrare EMPTAB are o valoare de intrare DEPTTAB are numărul maxim de valori de intrare ( ) DEPTTAB are valori de intrare Departamentul cu volumul maxim de vânzări are un angajat Departamentul cu volumul maxim de vânzări are angajați Departamentul cu volumul maxim de vânzări nu are angajați Toate departamentele din DEPTTAB au o cantitate egală de vânzări Departamentul cu cea mai mare cantitate de vanzari ocupa prima pozitie in DEPTTAB Departamentul cu cea mai mare cantitate de vanzari ocupa ultima pozitie in DEPTTAB Un alt angajat ocupa prima pozitie in EMRTAB Un alt angajat ocupă ultimul post în EMRTAB Un alt angajat - manager Un alt angajat nu este manager Un alt angajat nu este manager și are un salariu de , USD Un alt angajat nu este manager și are un salariu de , USD Un alt angajat nu este manager și are un salariu de , USD Valori limită de ieșire: ERRCODE = ERRCODE= ERRC DE = Salariul suplimentar este de , USD, care este maxim Următoarea condiție de testare se bazează pe ipoteza erorii Departamentul cu cea mai mare sumă de vânzări și fără angajați este urmat de un alt departament cu cea mai mare sumă de vânzări care are angajați pe lista sa Acest lucru se face pentru a determina dacă procesarea datelor de intrare a eșuat efectiv în cazul în care a fost generat un cod de eroare ERRCODE Din analiza celor de condiții enumerate mai sus, se poate observa că condițiile , și nu au nicio semnificație practică pentru construirea unui test Aceste condiții reprezintă situații care nu pot apărea În versiunea noastră, o astfel de presupunere este destul de acceptabilă, deși în cazul general este nesigură Următorul pas în construirea unui set de testare este să comparați restul de de condiții cu setul de testare existent (vezi Figura ) și să determinați care condiții la limită nu sunt încă acoperite de acesta Comparația arată că condițiile , , , , , , , , , și necesită o extindere a setului de testare deja existent prezentat în Fig Apoi, trebuie să proiectați teste suplimentare care să acopere aceste condiții limită O abordare posibilă este combinarea tuturor condițiilor cu testele existente (de exemplu, modificând într-un fel setul din Figura ) Dar nu este recomandat să se acționeze în acest fel, deoarece procedând astfel, se poate distruge cu neglijență caracterul complet al acoperirii combinatorii a condițiilor unui test deja existent Prin urmare, cel mai sigur mod de a construi un test este de a crea noi teste în plus față de cele prezentate în Figura , iar numărul de teste necesare pentru a acoperi condițiile limită ar trebui să fie minim Pe fig prezintă trei teste care îndeplinesc această cerință Testul acoperă condițiile , , , , , și , testul acoperă condițiile , , , iar testul acoperă condiția Deci, la construirea unui test acceptabil pentru modulul BONUS, a fost utilizată metoda de acoperire logică sau principiul cutiei albe, pe baza căruia testul prezentat în Fig , iar apoi pe principiu chipu black box au fost create teste suplimentare fig Test Intrare Ieșire estimată • ESIZE= DSIZE=* EMRTAB DEPTTAB Ollie E D , B , Cel mai bun E D , D B , Seltow E D , errcode=o ESIZE, DSIZE și DEPTTAB nu se modifică EMRTAV Olli E PZB , Cel mai bun E D , Seltow E B ESJZE= DSIZE= EMRTAB DEPTTAB B I ChZf I m I~P~gg , [ [ -DgȘ | OO^oF] ERRCODE= ESIZE, DSIZE și DEPTTAB nu se modifică EMRTAV [ Chiir W | D e| Sgg, ESIZE= DSIZE= EMRTAB DEPTTAB Dole E D , DE , Ford E D , WB , ERRCDEE= ESIZE, HSIZE și VERTTYAV nu se modifică EMRTYAV Dole E D Ford E D , Orez Teste suplimentare pentru analiza valorilor limită pentru modul TESTARE IN PAS Implementarea procesului de testare unitară se bazează pe două considerente cheie: construirea unei suite de teste eficiente (discutate în capitolul anterior) și alegerea modului în care unitățile sunt combinate pentru a construi un program de lucru din ele A doua prevedere este foarte importantă, deoarece definește forma în care sunt scrise testele modulelor, tipurile de instrumente utilizate în testare, ordinea în care modulele sunt codificate și testate, costul generării testelor și costul depanării (de ex , localizarea și remedierea erorilor) În această secțiune, vom analiza două abordări pentru combinarea modulelor: testarea pas cu pas și monolitică, iar în următoarea, două opțiuni Aceasta este o abordare treptată: testare de jos în sus (de jos în sus) și testare de sus în jos (de sus în jos) Apare întrebarea: ce este mai bine - să testați fiecare modul separat și apoi, combinându-le, să formați un program de lucru sau fiecare modul pentru testare? Orez Exemplu de program cu șase module pentru a vă conecta la un set de module testate anterior? Prima abordare este de obicei numită metoda de testare monolitică sau metoda „big hit” de testare și construire a programului; a doua abordare cunoscută ca metoda de testare pas cu pas sau de construire Ca exemplu, luați în considerare programul din fig Casetele reprezintă cele șase module de program (subrutine sau proceduri) linii este prezentată ierarhia de control: modulul A apelează modulele B, C și D, modulul B apelează modulul E și așa mai departe În abordarea tradițională monolitică, testarea se efectuează după cum urmează În primul rând, sunt testate șase module incluse în program, fiecare fiind testat independent de celelalte În diferite condiții (procesare în lot sau mod interactiv) și numărul de executanți, modulele pot fi testate secvenţial sau în paralel Modulele sunt apoi combinate sau asamblate într-un program (de exemplu, prin editarea link-urilor) Testarea oricărui modul necesită un modul driver dedicat și unul sau mai multe module stub De exemplu, dacă modulul B este testat, primul lucru de făcut este să dezvoltați teste și apoi să scrieți un mic program care să ofere modulului B datele de testare de intrare necesare pentru a-l executa (rulați testul) (În acest scop, puteți utiliza * În practica de programare, driverele sunt numite și module de depanare, iar stub-urile sunt numite și simulatoare - Notă ed De asemenea, driverul ar trebui să afișeze programatorului câteva informații despre rezultatele modulului B De asemenea, deoarece modulul B are un apel către modulul E, se recomandă să se realizeze un modul stub căruia să fie transferat controlul atunci când apelul către modulul E este executat , care este folosit în locul modulului E în timpul testării, primește și numele „E” și trebuie să imite funcțiile acestui modul După finalizarea testării tuturor celor șase module, acestea sunt asamblate într-un singur program Metoda de testare pas cu pas presupune că modulele nu sunt testate izolat unele de altele, ci sunt conectate unul câte unul pentru a efectua testul la un set de module testate anterior Numărul de implementări posibile ale metodei pas cu pas este mare, deci luarea în considerare a unei proceduri specifice pas cu pas pentru programul prezentat în Fig este încă prematur Întrebarea cheie este dacă testarea unui program ar trebui să înceapă de sus sau de jos Cu toate acestea, să lăsăm această întrebare până la următoarea secțiune și să presupunem că testarea începe de jos Inițial, puteți testa secvențial sau în paralel (de exemplu, trei persoane pot face acest lucru) modulele E, C și F În acest caz, va trebui să faceți un driver pentru fiecare modul; cioturile nu sunt necesare aici Următorul pas este testarea modulelor B și D, dar nu independent, ci împreună cu modulele E și, respectiv, F Cu alte cuvinte, pentru a testa modulul B, se dezvoltă un driver care include teste, iar perechea B-E este testată Procesul pas cu pas continuă până când ultimul modul, în acest caz modulul A, este conectat la setul de module testate Rețineți că această procedură poate fi dezvoltată și de sus în jos Deja în această etapă, putem face câteva generalizări: Testarea monolitică necesită multă muncă Pentru programul din fig , trebuie create cinci drivere și cinci stub-uri, având în vedere că modulul superior nu are nevoie de driver Testarea pas cu pas de jos în sus va necesita doar cinci drivere, iar de sus în jos, doar cinci stub-uri Reducerea costurilor cu forța de muncă se explică prin faptul că la testarea de sus în jos, modulele testate îndeplinesc funcțiile cioturi, iar la testarea de jos în sus - funcțiile driverelor În testarea pas cu pas, erorile în interfețele dintre module sunt detectate mai devreme, deoarece asamblarea programului începe mai devreme În schimb, în testarea monolitică, modulele nu se „văd” până în ultima fază a procesului de testare Depanarea programelor cu testare pas cu pas este mai ușoară Dacă există erori în interfețele dintre module, așa cum se întâmplă de obicei, acestea pot fi descoperite doar prin testare monolitică atunci când întregul program este construit În acest moment, este suficient să localizați eroarea dificil, deoarece poate fi localizat oriunde în program Dimpotrivă, cu testarea pas cu pas, erorile de acest tip sunt asociate în principal cu modulul care este conectat ultimul Rezultatele testului pas sunt mai perfecte De exemplu, la testarea modulului B, fie modulul A, fie modulul E este executat simultan (în funcție de faptul dacă testarea începe de sus sau de jos) Deși aceste module au fost deja testate temeinic înainte, utilizarea lor împreună cu modulul B va crea condiții noi și poate că unul dintre ele se va potrivi cu condiția care nu a fost luată în considerare în testarea lor de sine stătătoare Pe de altă parte, atunci când se testează o unitate în mod monolit, rezultatele sunt limitate doar la acea unitate Cu alte cuvinte, datorită faptului că în cazul testării în etape, modulele care au fost testate mai devreme sunt apoi folosite ca drivere sau stub-uri, acestea sunt supuse verificării suplimentare atunci când se execută testul modulului de depanat Consumul de timp de calculator pentru testarea monolitică este mai mic Dacă modulul A este testat folosind o abordare pas cu pas de jos în sus, atunci modulele B, C, D, E și, eventual, modulul F sunt executate simultan cu acesta, iar în cazul testării monolitice, numai modulul A în sine și stub-urile sunt executate în locul modulelor B, C și D Același lucru se întâmplă dacă se utilizează o abordare pas-cu-pas de sus în jos: dacă modulul F este testat, atunci modulele A, B, C, D și E pot să fie executat simultan cu acesta, în timp ce în testarea monolitică doar modulul F însuși este executat și corespunzător driverul corespunzător Prin urmare, numărul de instrucțiuni de mașină executabile în timpul testării cu testarea pas cu pas este în mod clar mai mare decât în cazul testării monolitice Cu toate acestea, acest exces este compensat de faptul că testarea monolitică necesită mai multe stub-uri și drivere decât testarea în pas și, ca urmare, timpul mașinii este alocat dezvoltării acestor drivere și stub-uri Utilizarea metodei monolitice oferă oportunități mari de organizare a muncii în paralel la faza inițială de testare (testarea tuturor modulelor simultan) Această prevedere poate fi importantă în implementarea proiectelor mari în care există multe module și mulți performeri, întrucât numărul de personal implicat în proiect este maxim în faza inițială În concluzie, observăm că itemii - demonstrează avantajele testării pas cu pas, iar itemii și arată dezavantajele acesteia Deoarece stadiul actual de dezvoltare a tehnologiei informatice tinde să reducă costul echipamentelor și să crească costul forței de muncă, consecințele erorilor în software-ul matematic sunt foarte grave, iar costul eliminării unei erori este cu atât mai mic cu cât aceasta este detectată mai devreme ; avantajele indicate la paragrafele - ies în prim-plan În același timp, prejudiciul cauzat de neajunsuri (punctele și ) este mic Toate acestea ne permit să concluzionam că testarea pas cu pas este de preferat telny DESCĂRCARE ȘI ACTUALIZARE TESTARE Convinși de avantajele testării în etape față de testarea monolitică, explorăm două strategii posibile de testare: de sus în jos și de jos în sus Inainte de Această afirmație consecventă din punct de vedere logic se poate dovedi a fi incorectă în anumite condiții De exemplu, dacă timpul de numărare al fiecărui modul real depanat este de câteva minute sau mai mult, iar timpul mașinii pentru a dezvolta un driver sau un stub este de zeci de secunde, atunci se observă relația opusă Atunci când alegeți o metodă de testare pentru o anumită dezvoltare, trebuie să luați în considerare caracteristicile software-ului, disponibilitatea resurselor și cerințele pentru gradul de depanare a produsului finit; în aceste condiții, timpul mașinii nu este întotdeauna factorul dominant chiar și pentru o dezvoltare mare - Notă ed Doar pentru a clarifica terminologia În primul rând, termenii testare de sus în jos, dezvoltare de sus în jos, proiectare de sus în jos sunt adesea folosiți în mod interschimbabil Într-adevăr, termenii „testare de sus în jos” și „dezvoltare de sus în jos” sunt sinonimi (în sensul că implică o anumită strategie în testarea și scrierea codului modulului), dar designul de sus în jos este un proces complet diferit și independent Un program proiectat de sus în jos poate fi testat atât de sus în jos, cât și de jos în sus În al doilea rând, dezvoltarea sau testarea de jos în sus este adesea echivalată cu testarea monolitică Această neînțelegere apare din faptul că începutul testării în sus este identic cu cel monolitic la testarea modulelor inferioare sau terminale Dar secțiunea anterioară a arătat că testarea de jos în sus este de fapt o strategie pas cu pas Acum că este clar că ambele strategii sunt • incrementale, nu vom discuta despre avantajele abordării incrementale; Luați în considerare diferența dintre strategiile de sus în jos și de jos în sus Testare descendentă Testarea de sus în jos începe cu modulul de sus, principal al programului Nu există o procedură strictă și corectă pentru conectarea următorului modul testat secvenţial Singura regulă care trebuie urmată la alegerea următorului modul este că acesta trebuie să fie unul dintre modulele apelate de modulul care a trecut anterior testul Pentru a ilustra această strategie, luăm în considerare Fig Programul descris pe acesta constă din douăsprezece module A-L Să presupunem că modulul J conține operații de citire din memoria externă, iar modulul I conține operațiuni de scriere Primul pas este testarea modulului A Pentru a realiza acest lucru, trebuie să scrieți module stub care înlocuiesc modulele B, C și D Din păcate, funcțiile îndeplinite de modulele stub sunt adesea înțelese greșit Deci, uneori puteți auzi că „stub-ul ar trebui să scrie doar un mesaj care să menționeze: „modulul conectat” sau „suficient to stub” Lushka a existat fără a lucra deloc” În cele mai multe cazuri, aceste afirmații sunt greșite Când modulul A apelează modulul B, A presupune că B lucrează, adică modulul A primește rezultatele muncii modulului B (de exemplu, sub forma valorilor variabilelor de ieșire) Când este modulul B Orez Exemplu de program cu douăsprezece module pur și simplu returnează controlul sau aruncă un mesaj de eroare fără a transmite niște rezultate semnificative lui A, modulul A nu funcționează corect din cauza erorilor din modulul în sine, ci din cauza unei nepotriviri a modulului stub cu acesta Mai mult, rezultatul poate fi nesatisfăcător dacă răspunsul modulului stub nu se modifică în funcție de condițiile de testare De exemplu, să presupunem că doriți să scrieți un stub care înlocuiește un program rădăcină pătrată, un program de căutare în tabel sau un cititor de înregistrări corespunzător Dacă stub-ul returnează întotdeauna același rezultat fix în loc de o anumită valoare pe care apelantul se așteaptă la acel apel anume, atunci apelantul fie va eșua (de exemplu, bucla) fie va produce o valoare de ieșire nevalidă Prin urmare, crearea modulelor stub nu este o sarcină trivială Când se discută despre metoda de testare de sus în jos, un alt punct este adesea trecut cu vederea, și anume, forma în care testele sunt prezentate într-un program În exemplul nostru, întrebarea este cum trebuie depuse testele modulul A? Răspunsul la această întrebare nu este în întregime evident, deoarece modulul superior dintr-un program tipic nu primește el însuși intrare și nu efectuează I/O Modulul superior (în cazul nostru, modulul A) primește date prin unul sau mai multe stub-uri Pentru a ilustra, să presupunem că modulele B, C și D îndeplinesc următoarele funcții: Orez Al doilea pas în testarea descendentă B - Obține un rezumat al fișierului suport; C - stabilește dacă starea de fapt săptămânală corespunde nivelului stabilit; D - generează un raport final pentru săptămână Într-un astfel de caz, testul pentru A este un rezumat al fișierului suport primit de la stub-ul B Stub-ul D conține instrucțiuni care își imprimă intrarea la o imprimantă sau la un terminal pentru a permite analiza rezultatelor trecerii fiecărui test Există o altă problemă cu acest program Deoarece modulul A apelează modulul B probabil o dată, trebuie să decidem cum să trecem mai multe teste lui A O soluție este să faci mai multe versiuni ale stub-ului în loc de B, fiecare cu un caz de testare fix Apoi, pentru a utiliza orice suită de testare, trebuie să executați programul de mai multe ori și de fiecare dată cu o nouă versiune a modulului stub care înlocuiește B O altă soluție este să scrieți seturi de testare în memoria externă, să le citiți cu un stub și să transferați le la modulul A În cazul general, crearea unui stub poate fi o sarcină mai dificilă decât în exemplul de mai sus În plus, este adesea necesar, datorită caracteristicilor programului, să se furnizeze unității testate date din mai multe stub-uri care înlocuiesc modulele de nivel inferior; de exemplu, un modul poate primi date de la mai multe module pe care le apelează După finalizarea testării modulului A, unul dintre stub-uri este înlocuit cu un modul real și se adaugă stub-urile necesare acestui modul De exemplu, în fig arată următoarea versiune a programului După testarea modulului superior (capul), testarea este efectuată în diverse secvențe Deci, dacă toate modulele sunt testate secvenţial, atunci sunt posibile următoarele opţiuni: ABCDEFGHIJKL AB EFJCGKD HLI ADHIKLCGBFJE ABFJDIECGKHL Când testarea este efectuată în paralel, pot apărea alte secvențe De exemplu, după testarea modulului A, un programator poate testa secvența A - B, altul - A - C, a treia - A - D În principiu, nu există o astfel de secvență care ar fi preferată, dar se recomandă să se respecte la două reguli de bază: Dacă programul are părți critice într-un anumit sens (eventual modulul G), atunci este recomandabil să alegeți o secvență care să includă aceste părți cât mai curând posibil Un modul critic poate fi un modul complex, un modul cu un nou algoritm sau un modul cu un număr semnificativ de erori așteptate (modul predispus la erori) Modulele care includ operațiuni I/O ar trebui, de asemenea, incluse în secvența de testare cât mai devreme posibil Oportunitatea primei reguli este evidentă, în timp ce a doua ar trebui discutată în continuare Amintiți-vă că atunci când proiectați stub-uri, apare o problemă că unele dintre ele trebuie să conțină teste, în timp ce altele trebuie să organizeze ieșirea rezultatelor pentru imprimare sau către terminal Dacă un modul real este conectat la programul ^, care conține operațiunile de intrare, prezentarea testelor este mult simplificată Forma de prezentare a acestora devine identică cu cea utilizată într-un program real pentru introducerea datelor (de exemplu, dintr-un fișier auxiliar sau intrare de la terminal) În mod similar, dacă plug-in-ul conține funcțiile de ieșire ale programului, atunci nu este nevoie de stub-uri care înregistrează Orez Stare intermediară în testarea descendentă rezultatele testului Fie, de exemplu, modulele J și I îndeplinesc funcții de intrare-ieșire, iar G să fie o funcție critică; atunci secvența pas cu pas ar putea fi după cum urmează: ABFJDICGEKHL iar după al șaselea pas devine așa cum se arată în Fig La atingerea stadiului prezentat în Fig , prezentarea testelor și analiza rezultatelor testelor sunt mult simplificate Există beneficii suplimentare În acest moment, există deja o versiune de lucru a structurii programului care efectuează operații reale I/O, în timp ce unele dintre funcțiile interne sunt imitate de stub-uri Această versiune de lucru vă permite să identificați erorile și problemele asociate cu organizarea interacțiunii cu o persoană; oferă o oportunitate de a demonstra programul utilizatorului, arată clar că întregul proiect este testat și pentru unii este, de asemenea, o creștere pozitivă a moralului Toate acestea, fără îndoială dar, meritele unei strategii de testare de sus în jos Cu toate acestea, testarea de sus în jos are o serie de dezavantaje serioase Fie ca starea programului testat să corespundă cu cea prezentată în Fig Următorul pas este înlocuirea stub-ului cu modulul H Pentru a testa acest modul, trebuie să proiectați (sau să le fi proiectat mai devreme) teste conform regulilor prezentate mai devreme în acest capitol Rețineți că toate testele trebuie prezentate ca date reale introduse prin modulul J Acest lucru creează două probleme În primul rând, există module intermediare (F, B, A și D) între modulele H și J, astfel încât este posibil să nu fie posibilă trecerea textului către modul care ar corespunde fiecărei situații descrise anterior la intrarea modulului H Pentru exemplu, dacă H este un modul BONUS prezentat în fig , se poate întâmpla ca, din cauza modulului intermediar D, să fie imposibil să se aplice toate cele șapte teste prezentate în Fig la intrarea modulului H și În al doilea rând, chiar dacă este posibil să treci toate testele, atunci, din cauza „distanței” dintre modulul H și punctul de intrare în program, apare o sarcină intelectuală destul de dificilă - să se estimeze care ar trebui să fie datele de la intrarea modulului J astfel încât să corespundă încercărilor solicitate ale modulului N A treia problemă este că rezultatele execuției testului sunt afișate de un modul care se află destul de departe de modulul care este testat în prezent Prin urmare, stabilirea unei corespondențe între ceea ce este arătat și ceea ce se întâmplă de fapt în modul este destul de dificilă și uneori pur și simplu imposibilă Să presupunem că adăugăm la circuitul din fig modulul E Rezultatele fiecărui test sunt determinate prin analiza ieșirilor modulului I, dar din cauza modulelor intermediare dintre modulele E și I, este dificil să se recupereze ieșirile reale ale modulului E (adică rezultatele pe care acesta le trece) la modulul B) În testarea de sus în jos, pot apărea încă două probleme în legătură cu organizarea implementării acesteia Unii programatori cred că testarea poate fi combinată cu proiectarea programului De exemplu, dacă programul prezentat în Fig , atunci s-ar putea să aveți impresia că, după ce ați proiectat primele două niveluri, ar trebui să mergeți la dezvoltarea și testarea modulelor A și B, C și D și dezvoltarea modulelor de nivel inferior După cum se menționează în [ ], o astfel de soluție nu este rezonabilă Proiectarea programului este un proces iterativ, adică atunci când se creează module care ocupă nivelul inferior în structura programului, poate fi necesar să se facă modificări la modulele de nivel superior Dacă modulele de nivel superior sunt deja codificate și testate, atunci cel mai probabil aceste modificări nu vor fi făcute, iar soluția adoptată anterior nu cea mai bună va avea o viață lungă Ultima problemă este că, în practică, este obișnuit să treceți la testarea următorului modul înainte de testarea celui precedent Acest lucru se datorează a două motive: în primul rând, este dificil să inserați date de testare în modulele stub și, în al doilea rând, modulele de nivel superior consumă resursele modulelor de nivel inferior Din fig Figura arată că testarea modulului A poate necesita mai multe versiuni ale stub-ului modulului B Programatorul care testează programul decide de obicei: „Nu voi testa imediat modulul A - acum aceasta este o sarcină dificilă Când conectez modulul J, va deveni mai ușor să prezint teste, iar apoi voi reveni la modulul de testare A ” Desigur, singurul lucru important aici este să nu uitați să verificați restul modulului când trebuia să fie făcut O problemă similară apare deoarece modulele de nivel superior solicită și resurse pentru utilizarea modulelor de nivel inferior (de exemplu, fișiere deschise) Este uneori dificil de determinat dacă aceste resurse au fost solicitate corect (de exemplu, dacă atributele de deschidere a fișierului sunt corecte) înainte până când începe testarea modulelor de nivel inferior folosindu-le Testare în amonte Luați în considerare o strategie de testare pas cu pas de jos în sus În multe privințe, testarea ascendentă este opusul testării descendente; Avantajele testării de sus în jos devin dezavantaje ale testării de jos în sus și invers, dezavantajele testării de sus în jos devin avantaje ale testării de jos în sus Având în vedere acest lucru, să discutăm pe scurt strategia de testare de jos în sus i stratul I Orez Stare intermediară în testarea ascendentă Această strategie presupune începerea testării de la module terminale (adică module care nu apelează alte module) Ca și până acum, nu există o astfel de procedură de alegere a modulului care urmează să fie testat în pasul următor, căruia i-ar fi acordat preferință Singura regulă este că următorul modul apelează modulele deja testate Dacă revenim la fig , primul pas ar trebui să fie testarea unora sau a tuturor modulelor E, J, G, K, L și I în serie sau în paralel Fiecare dintre acestea necesită un modul driver diferit, adică un modul care conține date de testare fixe, apelează modulul testat și afișează ieșirea (sau compară ieșirea reală cu ieșirea așteptată) Spre deosebire de stub-uri, un driver nu trebuie să aibă mai multe versiuni, așa că poate apela secvenţial unitatea testată de mai multe ori În cele mai multe cazuri, driverele sunt mai ușor de dezvoltat decât stub-urile Ca și în cazul precedent, secvența de testare este afectată de natura critică a modulului Dacă decidem că modulele D și F sunt cele mai critice, atunci starea intermediară va corespunde cu Fig Următorii pași ar putea fi să testați modulul E, apoi modulul B și să combinați B cu modulele E, F, J testate anterior Dezavantajul strategiei luate în considerare este că lipsește conceptul de construire a structurii programului de lucru într-un stadiu incipient al testării Într-adevăr, programul de lucru nu există până când nu este adăugat ultimul modul (în exemplu, modulul A), iar acesta este deja un program terminat Deși funcțiile I/O pot fi testate înainte ca întregul program să fie construit (modulele I/O utilizate prezentată în fig ), beneficiile proiectării timpurii a programului sunt în scădere Nu există probleme asociate cu imposibilitatea sau dificultatea de a crea toate situațiile de testare, care sunt tipice pentru testarea de sus în jos Driverul ca instrument de testare este aplicat direct pe modulul testat, nu există module intermediare de luat în considerare Analizând alte probleme care apar în testarea de sus în jos, se poate observa că în testarea de jos în sus este imposibil să se ia o decizie nerezonabilă de a combina testarea cu proiectarea programului, deoarece testarea nu poate începe până când modulele de nivel inferior nu sunt proiectate De asemenea, nu există nicio problemă cu testarea unui modul incomplet atunci când treceți la testarea altuia, deoarece testarea de jos în sus folosind mai multe versiuni ale unui stub nu are nicio problemă în prezentarea datelor de testare Comparaţie Din păcate, atunci când se compară strategiile de testare de sus în jos și de jos în sus, nu se pot opune între ele, așa cum sa făcut atunci când se compară abordările pas cu pas și monolitice În tabel Figura prezintă dezavantajele și avantajele lor relative (cu excepția avantajelor generale ca metode de testare pas cu pas) Primul avantaj al fiecăreia dintre metode ar putea fi un factor decisiv, dar este greu de spus unde sunt mai multe dezavantaje: în modulele de nivel superior sau în modulele de nivel inferior ale unui program tipic Prin urmare, atunci când alegeți o strategie, este indicat să cântăriți toate punctele din tabel luând în considerare caracteristicile unui anumit program Pentru programul exemplu, al patrulea dezavantaj al testării de sus în jos este de mare importanță Având în vedere acest dezavantaj și faptul că instrumentele de depanare reduc nevoia de drivere, dar nu de stub-uri, ar trebui să se prefere o strategie de testare de jos în sus În concluzie, observăm că strategiile de testare de sus în jos și de jos în sus considerate nu sunt singurele posibile cu o abordare pas cu pas În [ ], sunt luate în considerare încă trei variante ale strategiei de testare Tabelul Comparație între testarea de sus în jos și de jos în sus Avantaje și dezavantaje Testare descendentă Are avantaje, Are nevoie de dezvoltare dacă erorile sunt principalele module obvat-stubs împreună în vârful programului Reprezentarea unui test despre - Module stub des devine mai ușor după conectare, se dovedește a fi mai dificil, funcții de intrare - decât pare la început ieșire Formarea timpurie Înainte de aplicarea funcţiilor Structura programului I/O poate fi vă permite să-l desfășurăm de- dificil să reprezinte cei demonstrarea datelor utilizatorului în stub lu si serveste ca moral ki stimulent Poate fi dificil sau imposibil să se creeze condiții de testare Este mai dificil de evaluat rezultatele testelor Este permisă posibilitatea formării unei idei de combinare a testării cu designul Este stimulată nefinalizarea testării unor module Testare în amonte Are avantaje, Are nevoie de dezvoltare dacă erorile sunt în principal module-driver obvat deodată în modulul de nivel inferior Programul în ansamblu Mai ușor de creat cazuri de testare condiția întreg nu există până când Evaluarea mai ușoară a rezultatului camarad in ultimul modul EXECUTAREA TESTEI Execuția testului este etapa finală a testării unitare Mai jos este un set specific de îndrumări și îndrumări care ar trebui urmate în această etapă Dacă execuția testului dă rezultate care nu se potrivesc cu cele dorite, atunci aceasta înseamnă că fie modulul are o eroare, fie rezultatele așteptate sunt incorecte (o eroare în test) Pentru a elimina acest tip de neînțelegere, trebuie să verificați cu atenție suita de teste (testele „test”) c Utilizarea instrumentelor automate poate reduce complexitatea procesului de testare De exemplu, există instrumente care vă permit să scăpați de nevoia de șoferi Instrumentele de analiză a fluxului fac posibilă numerotarea rutelor din program, identificarea instrucțiunilor neexecutabile și găsirea locurilor în care sunt utilizate variabilele înainte de a li se atribui o valoare La pregătirea modulelor de testare, este recomandabil să revizuim din nou principiile psihologice și economice discutate în Cap Amintiți-vă că, așa cum sa arătat mai devreme, o parte necesară a suitei de teste este o descriere a rezultatelor așteptate Când executați un test, ar trebui să acordați atenție efectelor secundare, de exemplu, dacă un modul face ceva ce nu ar trebui să facă În cazul general, o astfel de situație este dificil de detectat, dar uneori efectele secundare pot fi detectate prin verificarea nu numai a variabilelor de ieșire așteptate, ci și a altora a căror stare nu ar trebui să se schimbe în timpul testării De exemplu, testul din Fig nu trebuie să modifice valorile variabilelor ESIZE, DSIZE și DEPTTAB Prin urmare, în timpul execuției sale, împreună cu rezultatele așteptate, este necesară verificarea acestor variabile În timpul testării modulelor, există și probleme psihologice asociate cu personalitatea testatorului Este bine ca programatorii să schimbe module, astfel încât să nu fie nevoiți să le testeze pe ale lor Astfel, programatorul care a realizat modulul apelant este un bun candidat pentru testarea modulului apelat Rețineți că acest lucru se aplică numai pentru testare, nu pentru depanare, care ar trebui să fie făcută întotdeauna de autorul modulului Nu următorul aruncați rezultatele testelor; prezentați-le în așa fel încât să le puteți reutiliza în viitor Luați în considerare posibilitatea de eroare reprezentare intuitivă (vezi Fig ) Dacă se găsesc un număr mare de erori într-un subset de module, atunci este probabil ca acele module să conțină un număr și mai mare de erori nedetectate Astfel de module ar trebui să facă obiectul unor teste suplimentare; este chiar de dorit să controlați sau să vizualizați suplimentar textul acestora În cele din urmă, trebuie amintit că sarcina testării nu este de a demonstra funcționarea corectă a modulelor, ci de a identifica erorile LITERATURĂ Muers GJ Compozit/Design structurat New York, Van Nost-rand Reinhold, M ers GJ Software Reliability: Principii și practici New York, Wiley-Interscience, Traducere rusă: Myers G Software Reliability M , Mir, CAPITOLUL TESTARE A COMPLEXELOR SOFTWARE Sfârșitul testării modulului nu înseamnă că testarea programului este finalizată De fapt, procesul de testare abia începe, mai ales dacă programul este mare sau este un produs software Această idee este confirmată de următoarea definiție a unei erori software [ ]: Un program are o eroare dacă este executat nu corespunde așteptărilor utilizatorilor Este clar că efectuarea chiar și a unei încercări absolut complete a unui modul nu ar garanta în niciun fel detectarea tuturor erorilor software (având în vedere definiția de mai sus) Acesta este unul dintre motivele pentru care trebuie dezvoltată o formă de testare suplimentară Un alt motiv este legat de descrierea preliminară a apariției erorilor software Faptul este că dezvoltarea de software este în mare măsură un proces de transfer de informații despre programul final și de traducere a acestor informații dintr-o formă în alta [ ] În plus, marea majoritate a erorilor software sunt determinate de defecte în organizarea muncii, de înțelegere reciprocă insuficientă și de distorsiuni în procesul de transfer și traducere a informațiilor Această vedere a dezvoltării software este ilustrată în Fig Figura , care prezintă un model de ciclu de dezvoltare a unui produs software Procesul de dezvoltare poate fi împărțit în șapte etape: În sistemul de standardizare de stat sovietic, se stabilește un set ușor diferit de etape și etape de dezvoltare Prin urmare, atât terminologia, cât și conținutul etapelor de dezvoltare date în această carte nu trebuie considerate ca fiind general acceptate Nevoile viitorului utilizator al programului în curs de dezvoltare sunt concretizate într-un document care descrie un set de cerințe pentru produsul dezvoltat Evaluând fezabilitatea și costul, rezolvarea cerințelor conflictuale, prioritizarea dezvoltării și livrării, aceste cerințe sunt traduse în obiective bine definite Pe baza acestor obiective, se creează o specificație detaliată și precisă a produsului software final, iar produsul în sine este considerat o cutie neagră și numai interfețele și interacțiunile sale cu lumea exterioară (de exemplu, cu utilizatorul final) sunt luat in considerare Această specificație se numește externă Proiectarea sistemului se realizează dacă produsul software este sisteme * (de exemplu, sistem de operare, sistem de control al traficului aerian, sistem de gestionare a bazelor de date, sistem de contabilitate a personalului) și nu un program (de exemplu, compilator, program de salarizare, format de text) La acest pas, sistemul este defalcat în programe, componente sau subsisteme individuale, iar interfețele acestora sunt definite ■■ Structura programului este concepută de special stabilirea (stabilirea) funcției fiecărui modul, a structurii ierarhice a tuturor modulelor și a tuturor interfețelor dintre module Se elaborează o specificație detaliată și precisă prin definirea interfeței și a funcției fiecărui modul Într-unul sau mai mulți sub-etași, specificația interfeței modulului este tradusă în algoritmul fiecărui modul scris în limba sursă Cu alte cuvinte, cerințele justifică de ce și se aplică necondiționat În același timp, experiența și practica dezvoltării de software în Statele Unite, reflectate aici, prezintă un interes indubitabil În prezent, se lucrează mult pentru a aduce standardele existente în conformitate cu practica modernă de creare a produselor software, atât în conținut, cât și în terminologie —■ Notă ed Pentru toate exemplele de mai sus, cu excepția primului, ar fi mai corect să spunem „este o parte integrantă a sistemului”, deoarece sistemele corespunzătoare includ și echipamente și personal În practica internă, în astfel de cazuri, se utilizează termenul „produs” sau „produs software”, spre deosebire de termenul „program” - Notă ed Utilizator final Cerințe co- inexacte user-fia tel (Extern specificație Proiect sisteme /Specificații în modulele X ugerface) Orez Procesul de dezvoltare software Proderni Pro-Verko Examinare Examinare Pra-Verka lanţuri Proiectarea sistemului Extern specificație Orez Proces de dezvoltare cu verificări intermediare Examinare examinare al-lea suport Proiectul Structura Programului J Specificațiile interfeței modulului sursă programul este necesar, obiectivele definesc ce ar trebui să facă programul și cât de bine ar trebui să o facă, specificațiile externe oferă o imagine exactă a programului de către utilizatorii săi, iar documentația asociată procesului secvenţial descris mai sus arată la toate nivelurile de detaliază cum este construit programul * Descrierea preliminară de mai sus a procesului de dezvoltare include transferul, înțelegerea și traducerea informațiilor de la pas la pas, precum și ipoteza că cel mai mare număr de erori software are loc datorită transformării pas cu pas a informațiilor Există trei metode suplimentare pentru prevenirea și/sau detectarea acestor erori Prima dintre ele se bazează pe creșterea clarității procesului de dezvoltare în sine, ceea ce va evita apariția multor erori A doua metodă este introducerea la sfârșitul fiecărui proces (etapă) a unui pas de verificare separat, care are ca scop localizarea celui mai mare număr de erori înainte de a trece la următorul proces (pas) Această metodă este ilustrată în Fig De exemplu, o specificație externă este verificată prin compararea acesteia cu rezultatul etapei anterioare (un raport care conține o descriere a obiectivelor), iar fiecare eroare găsită este returnată procesului de dezvoltare a specificațiilor externe (pe pas) pentru eliminare Metode de verificare a testului inițial și revizuirea lui end-to-end, discutate în Cap sunt utilizate în etapa de verificare la sfârșitul celui de-al șaptelea proces A treia metodă se concentrează pe procese specifice de cercetare În practica internă, cerințele pentru software (SW) sunt formulate în termenii de referință pentru produs, în care software-ul este inclus ca parte integrantă; obiectivele sunt indicate în termenii de referință pentru software O specificație externă a cerințelor nu este compilată ca document separat, dar documentele sau secțiunile relevante sunt furnizate ca parte a proiectului și a proiectului tehnic Informațiile pe care autorul își propune să le includă în proiectarea sistemului reprezintă conținutul principal al proiectului tehnic Proiectul de structură a programului și specificațiile interfeței modulului sunt documentație intermediară a proiectului de lucru În același timp, autorul subliniază pe bună dreptate necesitatea urgentă de a înregistra toate aceste informații sub formă de documente agreate de dezvoltatori și aprobate de proiectantul șef (și pentru termenii de referință, proiectele și proiectele tehnice - și de către client ) documente - Notă ed concentrându-se pe procese specifice de dezvoltare, adică concentrează fiecare proces de testare pe orice pas de traducere, în urma căruia un anumit Orez Relația dintre procesele de dezvoltare și testare clasa de eroare divizată Această metodă este ilustrată în Fig Ciclul de testare aici este structurat în modelul ciclului de dezvoltare prezentat în figură Astfel, este necesar să se poată stabili o corespondență unu-la-unu între procesele de dezvoltare și testare De exemplu, scopul testării modulelor este de a găsi inconsecvențe între modulele programului și specificațiile interfeței acestora, scopul testării funcționale este de a arăta că un program nu respectă specificațiile sale externe, scopul testării sistemului este de a demonstra inconsecvența un produs software cu obiectivele sale originale Avantajele structurii descrise sunt că evită testarea redundante neproductive și elimină posibilitatea unei întregi clase de erori De exemplu, în această metodă, testarea sistemului se concentrează pe o anumită clasă de erori (realizate la traducerea obiectivelor într-o specificație externă), iar caracteristicile acesteia sunt măsurate în raport cu un anumit tip de documentație creat în timpul procesului de dezvoltare Această abordare reprezintă o abatere semnificativă de la „testarea întregului sistem” prea simplistă, care uneori se limitează la simpla repetare a testelor create în etapele anterioare După cum sa menționat deja, formele de testare a pachetelor software (Figura ) sunt cele mai aplicabile produselor software (programe scrise în baza unui contract sau programe destinate utilizării generale; spre deosebire de programele experimentale sau de programele operate de autorul acestora) Programele care nu sunt un produs, de obicei, nu au cerințe și obiective formale; pentru ei, verificarea caracteristicilor este adesea singura verificare de nivel superior În plus, nevoia de testare de nivel superior crește pe măsură ce dimensiunea programului crește Motivul pare să fie că raportul dintre erorile de proiectare (erori făcute la începutul procesului de dezvoltare) și erorile de codare este mult mai mare în programele mari decât în programele mici Rețineți că secvența proceselor de testare (verificare) prezentată în Fig nu coincide neapărat cu succesiunea lor în timp >/ — pe mine De exemplu, deoarece testarea sistemului nu este definită ca „tipul de testare care urmează testării funcționale”, ci ca un tip special de testare care vizează identificarea unei anumite clase de erori, se poate suprapune în timp cu alte procese de testare Acest capitol acoperă procesul de testare a funcțiilor și sistemelor, testarea de acceptare și verificarea că sistemele software au fost instalate corect Verificarea rezultatelor asamblarii (complexării) nu este de obicei considerată o etapă separată, iar atunci când se utilizează testarea unitară în etape, este implicit inclusă în verificarea unității Toate întrebările sunt discutate într-un mod general, pe scurt și (în cea mai mare parte) fără exemple Acest lucru se datorează faptului că metodele speciale folosite în verificarea pachetelor software depind în mod semnificativ de specificul programului de verificat Astfel, caracteristicile unui test de sistem (tipuri specifice de cazuri de testare, felul în care sunt proiectate, mijloacele de verificare utilizate) pentru un sistem de operare diferă semnificativ de un test de sistem pentru un compilator, un program de control al reactorului nuclear sau o bază de date program de aplicare Ultimele secțiuni ale acestui capitol sunt dedicate planificării și organizării testării Aici este rezolvată și problema importantă a stabilirii momentului încetării acestuia TESTARE A FUNCȚIILOR După cum se arată în fig , testarea caracteristicilor se referă la găsirea diferențelor între un program și specificațiile sale externe O specificație externă este o descriere precisă a comportamentului unui program din punctul de vedere al „lumii exterioare” (de exemplu, utilizatorul) Testarea caracteristicilor se face de obicei într-o cutie neagră, cu excepția testării programelor mici Aceasta presupune că într-o etapă anterioară a testării unitare, criteriul de acoperire logică necesar inerent metodei cutiei albe este satisfăcut Pentru a crea un test de funcționare, specificația este analizată pentru a obține un set de teste Funcțiile cele mai potrivite pentru testare sunt cele descrise în Cap metode de partiţionare echivalentă, analiză valori la limită, diagrame funcționale, ipoteze de eroare Exemplele date în cap poate servi și ca exemple de teste de caracteristici Descrierile operatorului Fortran DIMENSION, sortatorul de date de examen și comanda DISPLAY sunt exemple reale de specificații externe (Rețineți, totuși, că acestea nu sunt încă pe deplin reale; astfel, programul de sortare trebuie să conțină în continuare o descriere exactă a formatelor de mesaje ) Prin urmare, exemple de teste funcționale nu sunt date aici Multe dintre regulile formulate în Cap Vezi ce funcții au cele mai multe erori Aceste informații sunt utile deoarece indică faptul că aceste funcții sunt susceptibile de a conține un număr mare de erori nedetectate O atenție considerabilă trebuie acordată condițiilor de intrare incorecte și neașteptate Amintiți-vă că definiția rezultatului așteptat este cea mai importantă parte a testului Când executați un test de caracteristici, rețineți că scopul unui test de caracteristici este de a găsi erori, nu de a arăta că programul se conformează specificațiilor sale externe TESTARE A SISTEMULUI Testarea sistemului este cel mai dificil proces de perceput și efectuat Nu ar trebui să fie echivalat cu testarea unui sistem sau program complet După cum se arată în fig , scopul testării sistemului este de a compara rezultatul cu obiectivele inițiale De aici rezultă două concluzii: Testarea sistemului nu se limitează la „sisteme” Dacă produsul este un program, atunci testarea sistemului este o încercare de a demonstra modul în care programul își atinge obiectivele Prin definiție, testarea unui sistem este imposibilă dacă în timpul proiectării nu a fost întocmit un document care să reflecte obiectivele stabilite pentru produs (sistem) Când se iau în considerare diferențele dintre rezultatul obținut și obiectivele originale ale programului, cea mai mare atenție este acordată identificării erorilor de traducere care apar în timpul dezvoltării unei specificații externe V * Acest lucru face ca verificarea sistemului să fie vitală, deoarece în această etapă apar cele mai multe erori și sunt destul de grave Spre deosebire de un test de caracteristici, o specificație externă nu poate fi utilizată ca bază pentru derivarea testelor de sistem, deoarece acest lucru ar înfrânge scopul unui test de sistem Pe de altă parte, un document care reflectă scopurile sistemului ca atare nu poate fi folosit pentru a-și formula testele: acesta, prin definiție, nu conține descrieri precise ale interfețelor externe ale sistemului Goluri progro/hhchy Donație Lopzobatölskor Isrikats speciali externi și I Orez Verificarea sistemului t grame Dilema este rezolvată prin utilizarea documentației operaționale pentru utilizator și a altor publicații (publicații) Testele de sistem sunt concepute pe baza unei analize a obiectivelor sale și apoi formulate pe baza rezultatelor studierii documentației utilizatorului Această practică este foarte utilă deoarece vă permite să comparați nu numai programele cu documentul sursă care descrie scopul creării sale, ci și rezultatele operațiunii sale cu documentația utilizatorului, precum și documentația utilizatorului cu documentul sursă, așa cum se arată în fig Testarea sistemului este cea mai dificilă parte a procesului de testare Sarcina sa principală este de a compara programul cu documentul sursă care descrie obiectivele creării acestuia (săgeata din stânga din Figura ) Cu toate acestea, nu există metodologii general acceptate pentru proiectarea unor astfel de teste Documentul sursă specifică exact ce ar trebui să facă programul și cât de bine ar trebui să se descurce, dar nu specifică cum ar trebui să fie prezentate funcțiile acestuia De exemplu, scopul comenzii DISPLAY specificat în cap ar trebui descris după cum urmează: Comanda pentru emiterea acesteia de la terminal trebuie să ofere o afișare a conținutului celulelor principale de memorie Sintaxa sa trebuie să fie compatibilă cu sintaxa tuturor celorlalte comenzi de pe sistem Utilizatorului trebuie să i se ofere posibilitatea de a specifica zona celulelor specificând fie adresele de început și de sfârșit, fie adresa de început și numărul de celule Pentru operanzii de instrucțiune trebuie furnizată o valoare implicită rezonabilă Rezultatele executării comenzii trebuie să fie afișate pe mai multe rânduri ca mai multe cuvinte (hexazecimale) cu spații între ele Fiecare linie trebuie să conțină adresa primului cuvânt afișat Această comandă este „trivială”, ceea ce înseamnă că atunci când este emisă, un sistem încărcat rezonabil începe să afișeze ieșirea după două secunde, fără întârziere vizibilă între afișarea liniilor de ieșire O eroare de programare în interpretul de comenzi, în cel mai rău caz, ar trebui să provoace execuția ei nereușită, dar să nu conducă la întreruperea sistemului și a sesiunilor utilizator Nu este permisă mai mult de o eroare în interpretul de comenzi după ce sistemul este lansat în producție Deci, deși obiectivele sunt formulate, nu există o metodologie identică, specifică, utilă, care să stabilească reguli de redactare a testelor care să demonstreze că un anumit program contrazice fiecare propoziție din documentul original Prin urmare, aici sunt prezentate diferite abordări ale proiectării testelor și sunt discutate categorii individuale de teste de sistem, mai degrabă decât o metodologie În legătură cu absența acestuia, în testarea sistemului ar trebui introdus un element de creativitate După cum știți, proiectarea unei suite de teste bune necesită mai multe abilități și experiență decât dezvoltarea aceluiași sistem sau program Cele categorii de teste sunt discutate mai jos Desigur, nu pretindem că toate sunt aplicabile oricărui program, dar este indicat să le studiem atunci când proiectăm teste Testare de utilizare Cel mai evident tip de testare a sistemului este testarea fiecărui element din documentul sursă (sau funcție, dar cuvântul „funcție” nu este folosit aici pentru a nu confunda testarea sistemului cu testarea caracteristicilor) Procedura de verificare constă în revizuirea secvenţială a documentului original (teză cu propoziţie) Dacă propoziția specifică o anumită sarcină (de exemplu, „sintaxa trebuie să fie compatibilă ”, „utilizatorul trebuie să poată specifica domeniul de adrese ”), atunci se stabilește dacă programul îndeplinește acea sarcină O astfel de verificare se poate face adesea fără un computer prin compararea mentală a obiectivelor cu conținutul documentației utilizatorului Limitați testarea * Al doilea tip de testare a sistemului este executarea unui program pe cantități mari de date De exemplu, intrarea unui compilator este un program sursă ridicol de mare, intrarea unui linker este un program care conține mii de module, iar intrarea unui program de modelare a circuitelor electronice este un circuit care conține mii de componente Coada de joburi a sistemului de operare se umple până la capacitate maximă Presupunând că programul trebuie să gestioneze fișierele aflate pe mai multe volume (să zicem, pe mai multe role de bandă), atunci vor fi suficiente date pentru a verifica dacă îl va forța să treacă de la un volum la altul Astfel, testarea limită ar trebui să arate că programul nu poate gestiona cantitatea de date specificată în obiectivele originale Testarea privind limitarea volumelor necesită, desigur, mult timp pe calculator Cu toate acestea, ele nu trebuie neglijate Dimpotrivă, fiecare program trebuie supus la cel puțin mai multe teste de anvergură Testare de sarcină finală Testarea de sarcină finală este verificarea performanței programului sub sarcini sau solicitări mari Nu trebuie confundat < cu testare la limitele volumelor: stres sever înseamnă sosirea unei cantități de vârf de date într-o perioadă scurtă de timp Aici puteți face o analogie cu evaluarea muncii unui dactilograf Când se testează la volume extreme, ar trebui să se stabilească dacă un dactilograf poate să se ocupe de o schiță a unui raport mare, iar atunci când se testează la sarcini maxime, dacă un dactilograf poate scrie cu o viteză de de cuvinte pe minut Deoarece testarea de stres implică un factor de timp, nu este aplicabilă multor programe, cum ar fi un compilator sau procesarea în loturi într-un program de salarizare Cu toate acestea, poate fi utilizat pentru programe care funcționează sub sarcini variabile, programe interactive sau în timp real și programe de control al proceselor Astfel, dacă un sistem de control al traficului aerian este de așteptat să urmărească până la de rute de aeronave în sectorul său, atunci ar trebui testat la sarcină maximă prin simularea prezenței a de aeronave Deoarece nu există niciun motiv pentru apariția celei de-a -a aeronave din sector, o creștere suplimentară a încărcăturii va duce la o reacție a sistemului la o aeronavă care nu va apărea niciodată Testul suplimentar de încărcare limită poate fi un test care simulează intrarea simultană a unui număr mare de aeronave într-un sector Să presupunem că sistemul de operare acceptă execuția a maximum joburi în modul multiprogram, apoi este încărcat prin rularea a joburi în același timp Dacă sistemul de partajare a timpului acceptă până la de terminale, încărcați-l cu o sarcină maximă: conectați de utilizatori la acesta, încercând să efectuați un apel simultan (Aceasta nu este o „situație care nu se va întâmpla niciodată”; ea apare în practică atunci când sistemul eșuează și operatorul îl restabilește imediat la funcționare) Pentru a determina răspunsul sistemului de simulare, imitați pe acesta acțiunile unui pilot care urmează un antrenament, cum ar fi rotirea volanului la stânga, pornirea Aici autorul este oarecum inconsecvent: în contextul ultimelor două secțiuni, aceasta seamănă mai mult cu testarea pe volume marginale - Notă ed bâzâit, coborârea clapetelor, ridicarea din față a aeronavei, retragerea trenului de aterizare, aprinderea luminilor de aterizare, înclinarea spre stânga - toate în același timp (Un astfel de test poate necesita prezența unui pilot „cu patru brațe” sau a doi testeri în cabină) Sistemul de control al procesului poate fi testat la sarcini maxime prin simularea emiterii simultane a semnalelor de la toate procesele controlate Sistemul de comutare telefonică este testat prin teste de limită de sarcină prin introducerea unui număr mare de apeluri în el în același timp Majoritatea testelor limită de sarcină sunt condiții similare cu cele care apar de fapt la intrarea programului în timpul funcționării acestuia Cu toate acestea, unele teste pot simula „situații care nu se vor întâmpla niciodată” Cu toate acestea, ele nu sunt utile Dacă erorile sunt detectate cu ajutorul lor, atunci sunt și ele necesare, deoarece este destul de probabil ca erori similare să apară și în situații reale nelimitative Testare de utilizare Un tip la fel de important de testare a sistemului este încercarea de a identifica problemele psihologice (de utilizator) sau problemele de utilizare Analiza factorilor psihologici este, din păcate, încă foarte subiectivă, întrucât nu s-a acordat suficientă atenție studiului și definirii aspectelor psihologice ale sistemelor software în producția de tehnologie informatică Mai jos este un test care vă permite să verificați unele proprietăți ale sistemului O Poate fi adaptată interfața dezvoltată pentru a informa și educa utilizatorul final, precum și pentru a asigura funcționarea acestuia în condiții reale? Sunt mesajele de ieșire ale programului semnificative, nu înjurături, inteligibile etc ? Diagnosticarea erorilor (de exemplu, mesajele de eroare) este de înțeles sau utilizatorul are nevoie de un doctorat în informatică pentru a le înțelege? De exemplu, programul produce mesaje precum „IEK A FROM FILE 'SYSIN' CLOSE, CRASH CODE = "? Întregul set de interfețe cu utilizatorul prezintă proprietatea importantă de „integritate conceptuală” [ ], consistența și uniformitatea sintaxei, convențiilor, semanticii, formatului, stilului și abrevierilor? Există o redundanță corespunzătoare în reprezentarea datelor de intrare (de exemplu, numărul de serie și numele clientului) în sistemele în care acuratețea este esențială (de exemplu, sistemele bancare online)? Sistemul conține opțiuni care sunt excesive sau puțin probabil să fie utilizate? Sistemul emite vreo confirmare pentru toate mesajele de intrare? Este programul ușor de utilizat? De exemplu, atunci când introduceți o comandă într-un sistem de partajare a timpului, trebuie să introduceți caractere de schimbare a majusculei înainte de caracterele majuscule și mici? Testare de securitate În societate, dorința de secretizare este în creștere, așa că multe programe au scopul de a proteja informațiile de accesul neautorizat Pentru testarea de securitate, este important să construiți teste care să distrugă securitatea software-ului, cum ar fi mecanismul de protecție a memoriei al sistemului de operare sau mecanismele de protecție a datelor ale sistemului de management al bazei de date O modalitate de a dezvolta astfel de teste este de a studia problemele de securitate cunoscute în aceste sisteme și de a genera teste care vă permit să verificați cum sunt rezolvate probleme similare în sistemul testat De exemplu, există descrieri [ , ] ale unor metode de asigurare a protecției în sistemele de operare Test de performanta Când se dezvoltă multe programe, sarcina este de a asigura productivitatea sau eficiența acestora Sunt determinate caracteristici precum timpul de răspuns și nivelurile de debit în anumite configurații hardware și sarcină Verificarea sistemului în aceste cazuri se reduce la a demonstra că programul nu îndeplinește obiectivele stabilite -lam Prin urmare, este necesar să se dezvolte teste cu ajutorul cărora se poate încerca să arate că ® nu are performanța necesară Testarea cerințelor de memorie Proiectarea unor sisteme va defini limitele privind cantitatea de memorie primară și secundară utilizată de un anumit program și dimensiunea fișierelor temporare sau spool Trebuie dezvoltate teste pentru a demonstra că obiectivele nu sunt îndeplinite Testarea configurațiilor hardware Sistemele de operare, sistemele de gestionare a bazelor de date și sistemele de comutare a mesajelor acceptă multe configurații hardware (de exemplu, tipuri și număr de dispozitive I/O și linii de comunicație, cantități diferite de memorie) Adesea, numărul de configurații posibile este prea mare pentru a încerca să testăm programul cu fiecare dintre ele Cu toate acestea, programul ar trebui testat cu cel puțin fiecare tip de hardware la configurații minime și maxime Dacă este posibil să schimbați configurația programului în sine (de exemplu, să nu includeți unele componente în el sau să plasați unele dintre ele pe un procesor separat), atunci este necesar să testați toate configurațiile posibile ale acestui program Testare de compatibilitate (conversii) Majoritatea software-ului dezvoltat nu este complet nou; adesea ele înlocuiesc sistemele de prelucrare a datelor imperfecte, învechite sau procesele neautomatizate Prin urmare, la dezvoltarea programelor, este necesar să se asigure compatibilitatea cu sistemul existent și să se creeze proceduri de conversie În acest caz, ca și în cazul altor forme de testare, testele ar trebui să fie orientate spre verificarea compatibilității și funcționarea procedurilor de conversie Conversia este înțeleasă ca procesul de trecere de la o metodă de prelucrare a datelor la alta și de la un sistem de prelucrare a datelor la altul - Notă ed aze Testare de utilizare a instalației Proceduri de instalare (setările) unor tipuri de sisteme software sunt destul de complexe (de exemplu, procesul de generare a sistemului sau „sysgen” în sistemele de operare IBM) Testarea unor astfel de proceduri face parte din procesul de testare a sistemului Testare de fiabilitate Desigur, scopul tuturor tipurilor de testare este de a crește fiabilitatea programului testat, dar dacă există instrucțiuni speciale în „documentul similar care reflectă obiectivele programului” privind fiabilitatea, pot fi dezvoltate teste speciale pentru a-l verifica Testarea fiabilității față de stabilirea obiectivelor poate fi dificilă De exemplu, în sistemul de comutare a mesajelor Beli System TSPS, timpul de nefuncționare nu ar trebui să fie mai mare de ore în de ani de funcționare Nu este posibil să se verifice îndeplinirea acestei proprietăți cu un timp de testare de câteva luni sau chiar ani Cu toate acestea, dacă programul trebuie să furnizeze un anumit timp între eșecuri (de exemplu, un timp mediu între eșecuri de de ore) sau este specificat un număr acceptabil de erori (de exemplu, programul trebuie să conțină cel mult erori după acesta) este transferat în producție), apoi Există o serie de modele matematice (vezi [ ], Cap ) care fac posibilă evaluarea validității unor astfel de cerințe Testare de recuperare Pentru sistemul de operare, sistemul de gestionare a bazelor de date și instrumentele de teleprocesare, este adesea specificat cum ar trebui să se recupereze sistemul de la erori software, defecțiuni hardware și erori de date La testarea sistemului, trebuie să arătăm că aceste funcții de recuperare nu sunt efectuate Puteți introduce în mod deliberat erorile software în sistemul de operare pentru a vedea dacă se va recupera după ce acestea sunt eliminate Defecțiunile hardware, cum ar fi erorile de I/O și paritatea memoriei, pot fi simulate Erori de date (interferențe în liniile de comunicație și incorecte valorile pointerului bazei de date) pot fi create sau modelate intenționat pentru a analiza modul în care sistemul reacționează la acestea Testare de service Documentul sursă articulează uneori obiective specifice pentru menținerea sau mentenabilitatea programului Acestea pot specifica facilitățile cu care ar trebui să fie furnizat sistemul (de exemplu, programe de descărcare a memoriei, programe de diagnosticare), timpul mediu de depanare a unei sarcini simple, procedurile de întreținere și calitatea documentației logicii interne a programului Toate aceste obiective trebuie testate Testarea documentației După cum se arată în fig , verificarea sistemului include și verificarea acurateții documentației utilizatorului Se verifică la determinarea corectitudinii reprezentării testelor anterioare ale sistemului (de exemplu, la proiectarea unui test de sarcină limită cu ajutorul documentației utilizatorului, este scris într-o formă reală, codificată) Documentația utilizatorului trebuie, de asemenea, să facă obiectul unei inspecții pentru acuratețe și claritate (similar cu inspecția codului sursă discutată în Capitolul ) Orice exemple date în documentație trebuie scrise ca test și prezentate la intrarea programului Testarea procedurii Multe programe fac parte integrantă din sisteme mari, nu complet automatizate, care includ proceduri efectuate de o persoană Toate aceste proceduri (proceduri ale operatorului de sistem, administratorului bazei de date, utilizatorului din spatele terminalului etc ) trebuie verificate la testarea sistemului Efectuarea unei verificări a sistemului Când verificați un sistem, este important să determinați cine exact ar trebui să-l efectueze Să aflăm această întrebare bom „dimpotrivă”: ) nu trebuie efectuată de programatori; ) nu trebuie efectuată de organizația responsabilă cu dezvoltarea programului Prima poziție se bazează pe faptul că testerul trebuie să gândească în aceleași categorii ca și utilizatorul final al programului, adică să înțeleagă toate relațiile și caracteristicile mediului și să aibă o idee bună despre cum este programul va fi folosit Evident, așadar, cel mai potrivit candidat în acest scop este utilizatorul final (unul sau mai mulți) Cu toate acestea, deoarece utilizatorul final obișnuit nu are de obicei capacitatea de a testa sau analiza rezultatele multor dintre tipurile de teste descrise mai devreme, este recomandabil să se creeze o echipă formată din mai mulți testeri profesioniști de sisteme (care își petrec toată viața testând sistemele) ), unul sau doi reprezentanți ai utilizatorului final , un specialist în psihologia ingineriei și unul dintre principalii analiști - autorii proiectului sau proiectanții programului Includerea acestuia din urmă nu încalcă principiul că autorul nu poate testa propriul program, deoarece acest program a fost probabil dezvoltat de o echipă de designeri și nu de această persoană În consecință, în acest caz, designerii principali nu au legături psihologice atât de puternice cu programul ca atunci când testează module și tocmai puterea legăturilor a fost motivul formulării acestui principiu În ceea ce privește a doua prevedere, trebuie menționat aici că organizația în curs de dezvoltare are legături psihologice cu programul Majoritatea organizațiilor de dezvoltare sunt extrem de interesate să se asigure că testarea sistemului se desfășoară „liniște” și la program Nu au niciun motiv să demonstreze că programul pe care l-au creat nu satisface obiectivele inițiale Validarea sistemului ar trebui să fie efectuată de cel puțin un grup independent de indivizi cu afiliere organizațională mică sau deloc cu organizația de dezvoltare Poate că cel mai rentabil mod de a testa sistemul (în sensul găsirii celor mai multe erori sau găsirii aceluiași număr de erori la un cost mai mic) este de a concluziona ne contract pentru implementarea lui cu orice companie Această problemă este discutată în detaliu în ultima secțiune a acestui capitol TESTE DE ACCEPTARE După cum arată modelul procesului de dezvoltare prezentat în Figura , testarea de acceptare este procesul de comparare a unui program dezvoltat cu un document inițial care reflectă cerințele inițiale pentru acesta și nevoile curente ale utilizatorilor săi finali Acesta este un tip de revizuire destul de neobișnuit, deoarece este efectuat de cumpărătorul sau utilizatorul final al programului și nu este responsabilitatea dezvoltatorului Autoritatea contractantă (utilizatorul) efectuează un test de acceptare a programului proiectat în temeiul contractului, comparând performanța sistemului cu cerințele contractului Este recomandabil să se efectueze o astfel de verificare prin aplicarea unor teste, cu ajutorul cărora se poate încerca să demonstreze că un anumit program nu îndeplinește cerințele contractului Dacă testul eșuează, programul dezvoltat este acceptat Un cumpărător rezonabil efectuează întotdeauna o verificare de acceptare pentru a se asigura că produsul software pe care îl achiziționează (de exemplu, un sistem de operare sau un compilator dezvoltat de un producător de computere, un sistem de gestionare a bazelor de date dezvoltat de o companie de software) îi satisface nevoile Autorul este poate prea laconic în a descrie acest tip de verificare a unui produs software Testele de acceptare (ACT), în timpul cărora sunt examinate caracteristicile externe ale produsului, sunt, de regulă, un proces în mai multe etape reglementat în practica internă de diverse documente de reglementare și tehnice Este deosebit de consumator de timp, complex și important în acceptarea software-ului pentru sistemele în timp real De exemplu, un program PSI pentru sisteme în timp real include de obicei toate tipurile de testare la care autorul s-a referit la testarea sistemului și la testarea corectitudinii instalării, precum și o serie de teste suplimentare Costul PSI poate fi destul de semnificativ Informații mai detaliate despre abordarea conducerii PSI în țara noastră pot fi găsite în cartea lui V V Lppaev „Designing ACS software Inginerie de sistem Arhitectură Tehnologie” (M , Radio sovietică, ) - Notă ed TESTAREA INSTALĂRII CORECTE Ultimul proces prezentat în fig , ■ - testarea instalării corecte Acest proces nu este asociat cu nicio fază a procesului de proiectare, ca toate celelalte procese de testare Este neobișnuit, deoarece scopul său este de a găsi erori de instalare, nu erori de software În timpul instalării sistemelor software, utilizatorul trebuie să selecteze multe opțiuni, să plaseze și să încarce fișiere și biblioteci, să repare configurația hardware corectă; cu toate acestea, acest program trebuie să fie legat de alte programe Scopul verificării este de a localiza toate erorile făcute în timpul procesului de instalare PLANIFICAREA ȘI CONTROLUL TESTEI Dacă vă imaginați că testarea unui sistem mare implică scrierea, executarea și verificarea a zeci de mii de teste, menținerea a mii de module, remedierea mii de erori și probabil sute de oameni care lucrează în momente diferite de-a lungul unui an sau mai mult, devine clar cât de mare problema este managementul proiectării, în special planificarea, managementul și controlul procesului de testare O carte întreagă ar putea fi dedicată managementului testelor software Prin urmare, această secțiune rezumă doar câteva considerații cu privire la această problemă Principalul defect în planificarea procesului de testare (vezi capitolul ) este că atunci când programați lucrul, se presupune că nu există erori în software Rezultatul unei astfel de calcule greșite poate fi o subestimare a resurselor planificate (oameni, calendar și timpul mașinii) Aceasta este o problemă cunoscută în calcul Se complică și mai mult de faptul că procesul de testare se încadrează în partea finală a ciclului de dezvoltare, când este deja dificil de manevrat resursele A doua și probabil mai semnificativă problemă este legată de definirea incorectă a testării Deoarece experiența utilizării definiției corecte a testării (scopul testării este de a găsi erori) este încă insuficientă, Verificarea este planificată în ipoteza că erorile nu vor fi detectate” Planificarea testelor este o parte majoră a procesului de testare Planul de testare include următoarele componente: Goluri Aici sunt definite obiectivele fiecărei faze de testare Criteriul de încetare Este indicat criteriul după care se înregistrează finalizarea fiecărei faze de testare Această problemă este discutată în secțiunea următoare Programe de lucru Programele de lucru sunt întocmite pentru fiecare fază de testare Acestea ar trebui să • reflecte momentul proiectării, codificării și implementării „Fără teste Responsabil Acesta specifică numele persoanelor care vor proiecta, codifica, executa și valida rezultatele testului în fiecare fază, precum și cei care vor corecta erorile găsite Arbitrul este numit și aici, deoarece în mare Când se discută rezultatele unui test, din păcate, apar adesea dispute (de exemplu, din cauza ambiguităților sau a definițiilor incorecte în specificații) Testați biblioteci și standarde Proiectele mari necesită metode sistematice de identificare, scriere și stocare a testelor Fonduri Sunt indicate instrumentele de testare necesare, inclusiv un plan care identifică dezvoltatorul sau viitorul proprietar al acestora, precum și cum și unde vor fi utilizate Timpul mașinii Este elaborat un plan pentru a oferi timp mașinii pentru fiecare fază de testare Configurare hardware Dacă este necesară o configurație hardware specială, atunci planul de testare Atunci când planificați testarea, este necesar să aveți material statistic extins și fiabil privind numărul mediu de erori pentru, de exemplu, o mie de comenzi ale unui produs software, timpul mediu pentru a găsi și remedia o eroare în diferite etape de testare și depanare , și costul acestor lucrări Experiența statistică insuficientă și lipsa standardelor relevante în prezent creează probabil dificultăți mai serioase în elaborarea programelor de lucru rezonabile decât simpla înțelegere sau înțelegere greșită a esenței proceselor de testare - Notă ed descrie etapele în care sunt necesare și cerințele pe care trebuie să le îndeplinească Complexarea Aceasta definește modul în care va fi construit programul (de exemplu, testarea pas cu pas în jos) Un sistem format din subsisteme sau programe poate fi asamblat pas cu pas (folosind o abordare de sus în jos sau de jos în sus dacă programele sau subsistemele sunt considerate componente mai degrabă decât module) În acest caz, planul de integrare este cu atât mai necesar Indică ordinea de integrare, capacitatea funcțională a fiecărei versiuni a acestui sistem și responsabilitatea pentru producția de „schele”, sau „recuzite” (coduri care modelează funcțiile componentelor inexistente) Proceduri de urmărire Este specificat un mijloc de urmărire a diferitelor aspecte ale progresului testului (inclusiv identificarea modulelor potențiale cu erori) și evaluarea acestuia în raport cu calendarul, resursele și criteriile de finalizare Proceduri de depanare Sunt determinate mecanismele de emitere a mesajelor despre erorile detectate, urmărirea compoziției și procedura de realizare a completărilor și modificărilor la sistem O parte a planului de depanare ar trebui să fie, de asemenea, programele de lucru, distribuirea responsabilităților, fondurile și timpul de lucru al mașinii Testarea regresiei Testarea de regresie se efectuează după îmbunătățirea funcțiilor programului sau după modificarea acestuia Scopul său este de a afla dacă o astfel de modificare a afectat negativ (indiferent dacă a condus la o regresie) alte proprietăți ale programului De obicei, se rezumă la reexecutarea unui subset de teste ale programului Testarea de regresie este importantă, deoarece modificările de cod și remedierea erorilor la un program tind să fie mai predispuse la erori decât codul sursă (o analogie poate fi trasă cu erorile tipografice din ziare; cele mai multe dintre ele sunt rezultatul modificărilor editoriale din ultimul moment și material sursă de calitate scăzută) Este necesar să se elaboreze un plan pentru efectuarea testelor de regresie (de exemplu, pentru a determina cine, cum și unde ar trebui să efectueze testul) - CRITERIU DE FINALIZARE VERIFICARE Una dintre cele mai dificile este întrebarea când să se termine testarea programului, deoarece nu este posibil să se determine dacă eroarea detectată este ultima Într-adevăr, chiar și pentru programele mici, ar fi nerezonabil să presupunem că toate erorile vor fi găsite în cele din urmă Cu toate acestea, testarea va trebui în cele din urmă să fie finalizată, fie și numai din motive economice Această problemă este de obicei decisă fie printr-o metodă pur volitivă, fie după un anumit criteriu (de multe ori lipsit de sens și neproductiv) În practică, următoarele criterii sunt cele mai utilizate: Timpul alocat pentru testare conform programului de lucru a expirat Toate testele sunt finalizate fără a detecta erori (adică eșuează) Ambele criterii sunt inutile; primul poate fi satisfăcut fără a face nimic (adică nu conține o evaluare a calității testării); al doilea nu are sens, deoarece nu depinde de calitatea testelor În plus, cel de-al doilea criteriu este neproductiv, deoarece încurajează în mod subconștient construirea de teste cu o probabilitate scăzută de a detecta o eroare După cum sa menționat deja în cap , gândirea umană este concentrată pe obiectiv Dacă un programator își stabilește scopul de a rezolva o problemă cu teste eșuate, atunci el va dezvolta în mod subconștient teste care îl conduc la acest scop, evitând construirea de teste distructive utile cu detectabilitate ridicată Există trei categorii de criterii mai mult sau mai puțin acceptabile Prima dintre acestea include criterii (departe de cele mai bune) bazate pe utilizarea anumitor metodologii de proiectare a testelor De exemplu, este posibil să se definească condiția de terminare pentru testarea unui modul folosind teste obținute în două moduri: ) prin îndeplinirea criteriului de acoperire combinatorie și ) prin analiza valorilor limită conform specificației interfeței modulului Toate testele rezultate trebuie să eșueze în cele din urmă Sfârșitul testării caracteristicilor poate fi definit atunci când sunt îndeplinite următoarele condiții: testele obținute prin metode de ) diagrame funcționale, ) analiza valorii la limită, ) ghicirea erorilor, trebuie în cele din urmă să eșueze Deși aceste criterii sunt mai bune decât cele două definite anterior, există trei probleme cu ele În primul rând, ele sunt inutile într-o fază de testare în care anumite metodologii devin inutilizabile, cum ar fi faza de testare a unui sistem În al doilea rând, o astfel de măsurare este subiectivă, deoarece nu există nicio garanție că acest specialist a folosit metodologia necesară (de exemplu, analiza valorii la limită) corect și precis În al treilea rând, în loc să stabilească un obiectiv și să ofere posibilitatea de a alege cea mai potrivită modalitate de a-l atinge, criteriile luate în considerare prescriu utilizarea unor metodologii specifice de proiectare a testelor, dar nu stabilesc niciun scop Astfel, criteriile din prima categorie sunt utile pentru unele faze de testare, dar ar trebui folosite doar dacă ai deja experiență cu aceste metodologii Criteriul celei de-a doua categorii, aparent, este de cea mai mare valoare, deoarece formulează clar condiția de finalizare a testului Deoarece scopul testării este de a găsi erori, de ce să nu alegeți un număr predeterminat de erori ca criteriu? De exemplu, puteți seta verificarea modulului să se termine după ce sunt găsite trei erori Poate că condiția pentru finalizarea verificării sistemului ar trebui să fie detectarea și eliminarea a de erori sau durata totală a verificării luni, oricare dintre acestea survine primul Rețineți că un astfel de criteriu confirmă definiția testării Există două probleme fundamental rezolvabile asociate cu acesta Una dintre ele este de a stabili o modalitate de a obține numărul de erori detectate Este nevoie de: Estimați numărul total de erori din program Aflați ce procent din aceste erori pot fi găsite prin testare Determinați care parte dintre erori au apărut în timpul procesului de proiectare și în care faze de testare este recomandabil să le identificați * O estimare aproximativă a numărului total de erori poate fi obținută prin mai multe metode Una dintre ele se bazează pe analiza datelor privind dezvoltarea altor programe Există o serie de modele de predicție (de exemplu, [ ], cap ), dintre care unele necesită să testați programul pentru o anumită perioadă de timp, să fixați intervalele de timp dintre detectarea erorilor succesive și apoi să înlocuiți aceste intervale ca parametri în formulă Unele modele presupun că erorile sunt introduse artificial în program, dar prezența lor nu este anunțată Programul este testat un anumit timp, după care se verifică raportul erorilor detectate și nedetectate dintre cele care au fost introduse în el Există modele care presupun că programul este depanat de două echipe de testare independente pentru un anumit timp, iar apoi sunt analizate erorile găsite de fiecare echipă și erorile găsite de ambele echipe împreună Acești parametri sunt utilizați pentru a estima *numărul total de erori O altă metodă „en-gros” de obținere a unei astfel de estimări se bazează pe medii statistice utilizate pe scară largă în industrie De exemplu, numărul de erori care există în programele tipice până la finalizarea codificării timpului (înainte de o inspecție) este de aproximativ - la de operatori de program Determinarea procentului de erori care pot fi găsite prin testare ar trebui să țină cont de natura programului și de consecințele erorilor nedetectate și poate fi oarecum arbitrară Determinarea erorilor care apar în timpul procesului de proiectare este foarte dificilă, deoarece în prezent practic nu există informații despre acestea Dovezile sugerează că în programele mari, aproximativ % din toate erorile sunt erori de proiectare de logică și codare, restul fiind generat în etapele anterioare de proiectare Să lămurim cu un exemplu simplu, deși cititorul care dorește să folosească acest criteriu trebuie să-și elaboreze propriile estimări pentru a se potrivi programului său Să presupunem că testăm un program de de declarații; numărul de erori rămase după inspecțiile codului sursă este estimat la cinci la de operatori Scopul testării este de a detecta % dintre erorile de codare și logice și % dintre erorile de proiectare Astfel, numărul total de erori este de Se presupune că dintre ele sunt erori de codare și de logică, iar sunt erori de proiectare Prin urmare, este necesar să găsiți de erori de codare și logice și de erori de proiectare În tabel pe- Tabelul Estimarea ipotetică a distribuţiei erorilor pe etape de verificare Erori de codificare și logice Erori de proiectare Verificare modul % % Test de funcționare % % Verificare sistem % % Total % % este indicat în ce stadiu de testare ar trebui detectate Dacă programul este de patru luni pentru testarea caracteristicilor și trei luni pentru testarea sistemului, atunci pot fi setate următoarele criterii de finalizare: S-au găsit și au remediat de erori ( % din cele de erori de codare și logică estimate) de erori găsite și remediate ( % din plus % din ) sau patru luni de testare a caracteristicilor au expirat, oricare dintre acestea survine mai târziu (Faptul este că, dacă de erori sunt găsite rapid, atunci acest lucru poate însemna că numărul lor total este subestimat, nu ar trebui să opriți testarea funcțiilor ) Au fost găsite și remediate erori sau au trecut trei luni pentru testarea sistemului, indiferent de eveniment care are loc mai târziu O altă problemă evidentă asociată cu criteriul celei de-a doua categorii este problema supraestimării Ce se întâmplă dacă, în exemplul de mai sus, au rămas mai puțin de de erori până la începerea verificării caracteristicilor? Pe baza acestui criteriu, nu va fi niciodată posibilă finalizarea fazei de testare a caracteristicilor Apare o situație destul de ciudată: nu există suficiente erori, programul se dovedește a fi și el com „bine” S-ar părea că nu ar trebui să fie nicio problemă, deoarece tocmai pentru asta ne străduim Cu toate acestea, dacă apare, este nevoie doar de puțin bun simț pentru a o rezolva Dacă de erori nu pot fi găsite în patru luni, managerul de proiect poate invita un expert din partea care, după analiza după rularea testelor, el își va exprima părerea despre cauzele problemei: testele pot fi inadecvate ( ) sau reușite ( ), dar există într-adevăr puține erori în program Al treilea criteriu de categorie se bazează în mare măsură pe bunul simț și intuiție Pentru a-l utiliza în faza de verificare, este necesar să se traseze numărul de erori găsite pe unitatea de timp Analizând forma curbei, este adesea posibil să se determine dacă testul trebuie să continue într-o anumită fază sau să-l încheie și să treacă la următoarea Lăsați un program să treacă prin faza de testare a funcțiilor Construim un grafic al numărului de erori găsite în el pe săptămână Chiar dacă este îndeplinit criteriul pentru numărul necesar de erori, curba de peste șapte săptămâni de testare este de așa natură (Figura din stânga) încât nu este înțelept să opriți testarea funcțiilor acestui program Deoarece rata de detectare a erorilor este mare (au fost găsite o mulțime de erori), soluția cea mai corectă (având în vedere că scopul nostru este să le găsim) este să continuăm testarea funcțiilor cu proiectarea dacă sunt necesare teste suplimentare A S perioade bisăptămânale Orez Examinarea proceselor de testare la sfârșitul unui proiect mare viteza, cu atât mai bine), mergi la fel Pe de altă parte, să presupunem că graficul are forma prezentată în Fig corect Eficiența detectării erorilor a scăzut semnificativ, așa că puteți termina testarea caracteristicilor și puteți trece la următoarea fază, cum ar fi testarea sistemului (Desigur, trebuie să luăm în considerare și alți factori care ar putea duce la o scădere a eficienței detectării erorilor: lipsa timpului de calculator sau capacitatea scăzută de detectare a testelor existente ) Pe fig Figura arată ce se întâmplă atunci când uitați să reprezentați numărul de erori găsite Diagrama descrie cele trei faze ale testării unui sistem software foarte mare [ ]; a fost construită ca urmare a studiului acestui proiect după finalizarea acestuia Concluzia este evidentă: după cea de-a șasea perioadă nu a fost necesar să se treacă la alte faze de testare Pe parcursul celei de-a șasea perioade, rata de detectare a erorilor a fost ridicată (și pentru testare, cu atât este mai mare pentru următoarea fază a dus la o scădere semnificativă Cel mai bun criteriu de finalizare a testului este probabil o combinație a celor trei criterii discutate mai sus Pentru testarea unitară, primul criteriu de terminare va fi evident optim, deoarece în majoritatea proiectelor această fază nu urmărește numărul de bug-uri găsite; aici este important ca un set specific de metodologii de proiectare a testelor să fie utilizat În timpul fazelor de testare a funcțiilor și a sistemului Cree Criteriul de terminare poate fi oprirea atunci când se atinge un număr prestabilit de erori detectate sau când se atinge un timp predeterminat de programul de lucru, oricare dintre acestea survine mai devreme (cu condiția ca o analiză a diagramei numărului de erori în funcție de timpul de testare să arate o scăderea productivității acestui test) AGENȚII INDEPENDENTE DE TESTARE Mai devreme în acest capitol și cap a subliniat că o organizație nu ar trebui să testeze programele pe care le-a dezvoltat pe motiv că poate avea dificultăți în încercarea de a testa în mod obiectiv produsul pe care l-a creat În structura organizatorică a acestei companii, organizația de testare (testare) ar trebui să fie cât mai departe de organizația în curs de dezvoltare Este chiar de dorit ca organizația de audit să nu facă parte deloc din această firmă, deoarece, fiind parte integrantă a acesteia, se află într-un singur sistem organizațional cu organizația în curs de dezvoltare Astfel, Forțele Aeriene ale SUA au încheiat la un moment dat un contract pentru dezvoltarea de software cu o organizație și un contract pentru testarea acestui software cu alta [ ] Forțele Aeriene au acum propria sa organizație de testare, independentă din punct de vedere administrativ (Centrul Forțelor Aeriene pentru Inspecție și Evaluare) și practica de a folosi contractori de testare independenți de contractorii de dezvoltare [ ] Eficacitatea acestui pas este evidentă [ ]: „Una dintre cele mai de succes abordări pentru îmbunătățirea fiabilității software-ului, care este utilizat în prezent de către Forțele Aeriene, în special în ceea ce privește cel mai important software de fiabilitate al sistemelor în timp real , este utilizarea agențiilor independente pentru analiză, testare și evaluare globală a software-ului Beneficiile observate de obicei sunt sporite de motivarea procesului de testare, concurența sănătoasă cu organizația de dezvoltare, separarea procesului de testare de controlul administrativ al organizației de dezvoltare și experiența acumulată mare pe care se bazează agențiile independente de testare pentru a rezolva acest lucru problemă Daca asta Ce practică se va răspândi, va deschide oportunități suplimentare pentru dezvoltarea unui nou tip de activitate financiară în domeniul prelucrării datelor LITERATURĂ Myers GJ Software Reliability: Principii și practici New York, Wiley-Interscience, Traducere rusă: Myers G Software Reliability M , Mir, În g despre ks F R Jr The Mythical Man-Month: Essays on Software Engineering, Reading, Mass , Addison-Wesley, Traducere rusă: F P Brooks Cum sunt proiectate și construite sistemele software M , Nauka, Integritatea sistemului de operare M c P h e WS în OS/VS — IBM Systems J , ( ), p - Pinchuk PL TRW Evaluarea unui sistem de operare sigur — Securitatea datelor și prelucrarea datelor, V , Experiențe de evaluare și instalare: Sistem de securitate a resurselor White Plains, NY, IBM, , p G - Raig CR și colab Studiu de fiabilitate software - RADC-TR- - , TWR Corp , Redundo Beach, Cal , S he i y M Fiabilitatea software-ului de calculator: fapt sau mit? - TR-MMER/RM- - , Hill Air Force Base, C'tah, Magi CR Rolul unei agenții independente de validare a software-ului - Raportul - , Defense Systems Management School, Fort Belvoir, Va, Fiabilitatea software-ului Thayer RH și Hinton ES - O metodă care funcționează — Proceedings of the National Computer Conference Montvale, NJ, AFIPS Press, , p - CAPITOLUL DEBUG Pe baza definițiilor furnizate mai devreme în această carte, depanarea unui program poate fi considerată ca un proces care are loc după ce un test a fost finalizat cu succes Procesul de depanare începe atunci când este detectată o eroare (de exemplu, la finalizarea cu succes a testului) și se desfășoară în două etape: ) se determină natura și locația erorii suspectate în program; ) eroarea este remediată sau corectată Trebuie remarcat faptul că depanarea este singura parte a procesului de dezvoltare a software-ului pentru care programatorii nu o plac Motivele acestei atitudini par să fie următoarele: Programatorii care nu folosesc „programarea impersonală” [ ] deseori consideră că depanarea este dificilă din punct de vedere psihologic, deoarece, atunci când este făcută, se dovedește că nu sunt perfecți (adică greșesc în proiectarea și codificarea programelor) Dintre toate activitățile de dezvoltare software, depanarea este cea mai solicitantă din punct de vedere intelectual Mai mult, de obicei se realizează sub o presiune enormă (organizațională sau internă, cauzată de dorința de a remedia cât mai repede posibil eroarea suspectată), ceea ce complică foarte mult problema Metodele existente și natura majorității limbajelor de programare sunt de așa natură încât orice eroare poate apărea în orice instrucțiune de program De exemplu, fără o verificare inițială, este teoretic imposibil să se excludă posibilitatea ca erorile numerice în valorile cecurilor plătite primite de programul de salarizare să fie rezultatul unei erori conținute într-o subrutină care solicită operatorului sistem pentru a specifica formularul de eliberare a rezultatului către dispozitivul de imprimare Acest lucru este complet diferit de repararea unui sistem fizic ca o mașină În cazul unei opriri neprevăzute a vehiculului (simptom), excludem imediat și destul de rezonabil părți ale sistemului care nu pot fi cauza defecțiunii acestuia (de exemplu, radio, vitezometru, tijă de blocare) Este mai mult despre motor, iar pe baza cunoștințelor generale despre motorul mașinii, anumite componente (pompa de apă și filtrul de ulei) pot fi excluse În comparație cu alte etape ale dezvoltării software, procesul de depanare este puțin studiat și puțin acoperit în literatură Nu sunt emise suficiente instrucțiuni formale pentru implementarea acestuia Deși subiectul acestei cărți este testarea, nu depanarea, o scurtă discuție despre depanare aici este justificată, deoarece ambele procese sunt strâns legate Dintre cele două aspecte ale depanării (localizarea erorii și remedierea acestuia), primul reprezintă până la % din soluția problemei Prin urmare, acest capitol se concentrează pe găsirea locației unui bug atunci când există dovezi că bug-ul există (adică, pe baza rezultatelor unui test de rulare) METODE DE FORŢĂ Cele mai comune la depanarea unui program sunt metodele destul de ineficiente de „forță brută” Motivul pentru popularitatea acestor metode, probabil, este că nu necesită multă atenție și efort mental mare Metodele de forță brută pot fi împărțite în cel puțin trei categorii: ) depanare cu ajutorul unui dump de memorie; ) depanare în conformitate cu propunerea generală „aranjați declarațiile de tipărire pe tot parcursul programului”; ) depanare folosind instrumente automate Cel mai puțin eficient dintre acestea este depanarea prin analizarea unui dump de memorie (de obicei, o afișare brută a stării întregii memorie în octal sau hexazecimal) Are urmatoarele probleme: Dificultate în stabilirea corespondenței între celulele de memorie și variabilele din programul original O cantitate semnificativă de date oferite, multe dintre ele nu sunt utilizate De fapt, imprimarea stării memoriei este o afișare statică a programului (adică starea acestuia doar la un moment dat), dar pentru a găsi cele mai multe erori, dinamica execuției acestui program (adică, modificarea acestuia) stare în timp) trebuie studiat În practică, o imprimare a stării memoriei este rareori obținută exact în punctul din program în care este localizată eroarea Prin urmare, dump-ul nu reflectă starea programului în punctul care conține eroarea; acțiunile întreprinse între momentul în care apare o eroare și momentul în care este primită descărcarea pot împiedica localizarea erorii Lipsa metodologiilor descrise în literatura de specialitate pentru identificarea cauzei unei erori prin analiza unui dump de memorie (mulți programatori se uită pur și simplu la dump, așteaptă în mod evident ca eroarea să se dezvăluie magic) Metodele din a doua categorie, în care instrucțiunile de afișare a valorilor variabilelor sunt plasate în programul care conține eroarea, sunt oarecum mai bune Aceste metode au multe dezavantaje, dar ele sunt adesea preferate în detrimentul depozitelor Acestea vă permit să afișați dinamica execuției programului și să vizualizați informații care sunt mai ușor de corelat cu textul sursă Iată câteva dintre deficiențele lor: Aranjarea instrucțiunilor de tipărire într-un program forțează în mare măsură programatorul să lucreze prin încercare și eroare, în loc să-l încurajeze să se gândească la problema din fața lui în timpul depanării În timpul depanării, poate fi necesar să se analizeze o cantitate mare de date Aici trebuie să schimbați programul la depanare; aceste modificări pot ascunde o eroare, pot întrerupe relațiile de timp critice sau pot introduce noi erori în program Costul utilizării metodelor din această categorie pentru programe sau sisteme mari poate fi enorm, dar pentru programele mici sunt destul de aplicabile În plus, nu sunt potrivite pentru anumite tipuri programe (de exemplu, sisteme de operare, programe de control al proceselor) Metodele din a treia categorie, care folosesc instrumente de depanare automată, sunt similare cu metodele din a doua categorie, dar diferă de acestea în ceea ce privește efectuarea modificărilor în program Analiza dinamicii execuției programului se realizează cu ajutorul instrumentelor de depanare ale limbajului de programare sau a instrumentelor speciale de depanare interactive Caracteristicile tipice ale limbajului care pot fi utilizate sunt cele care oferă imprimări ale urmelor instrucțiunilor executate, subrutine de apel și/sau modifică variabilele specificate Funcția generală a instrumentelor de depanare este de a seta un set de „puncte de întrerupere” care fac ca execuția programului să se întrerupă după executarea unei anumite instrucțiuni sau modificarea valorii unei anumite variabile și permițând programatorului care lucrează la terminal să verifice starea curentă a programului Cu toate acestea, aceste metode sunt în mare măsură încercări și erori, iar rezultatele lor conțin adesea o cantitate excesivă de date redundante O problemă comună cu metodele de forță brută este că acestea ignoră procesul de deliberare Puteți face o analogie între depanarea unui program și investigarea unei crime De fapt, în toate romanele polițiste, misterul este rezolvat prin analiza atentă a dovezilor și combinația de detalii aparent nesemnificative, mai degrabă decât prin metode de forță brută, cum ar fi blocarea străzilor sau căutarea proprietății De exemplu, așa s-au rezolvat o serie de crime cu arme de calibru din New York în - Suspectul a fost reținut nu prin metode de „forță brută” (saturarea companiilor aeriene și a ziarelor cu portrete ale lui de către artist și creșterea numărului de polițiști pe străzi), ci prin găsirea mai multor indicii aparent nesemnificative, dintre care unul era un bilet către parcarea S-a dovedit experimental [ , ] (și acest lucru este valabil atât pentru programatori începători, cât și pentru programatori experimentați) că instrumentele de depanare nu ajută procesul de depanare și că programatorii care preferă să se gândească la rezultatele unei rulări decât să execute fără scop în mod repetat un program pe aceleasi teste rapid găsiți erorile mai precis Prin urmare, utilizarea metodelor brute-force este recomandată numai dacă toate celelalte metode au eșuat sau, în plus față de (dar nu în locul) proceselor deliberative descrise în secțiunile următoare METODA DE INDUCȚIE Se crede că majoritatea erorilor pot fi găsite printr-o analiză atentă, în multe cazuri fără a merge măcar la aparat Una dintre aceste metode este inducția, timp în care Orez Proces de depanare inductivă analiza se face de la particular la tot În același timp, privind detaliile (simptome de eroare, eventual stabilite de unul sau mai multe teste) și relația dintre acestea, se poate ajunge adesea la o eroare Procesul de inducție este prezentat în fig Se împarte în următorii pași: Determinarea datelor relevante pentru eroare Principala greșeală care apare în depanarea programelor prost organizată este că toate datele disponibile sunt luate în considerare sau simptome legate de sarcină Primul pas ar trebui să fie să enumerați toate acțiunile care indică execuția corectă a programului și toate acțiunile sale incorecte (adică, simptomele care conduc la concluzia că există o eroare) Date suplimentare de eroare se obțin prin efectuarea unor teste similare care nu provoacă simptomele indicate Organizarea datelor Inducția implică o analiză de la particular la general, deci al doilea pas este structurarea datelor relevante pentru eroare pentru a identifica unele modele De o importanță deosebită este studiul inconsecvenței (de exemplu, „o eroare apare doar atunci când contul clientului are un sold debitor – pozitiv”) Foarte utilă este tehnica organizatorică cunoscută sub numele de „Metoda” [ ] Tabelul prezentat în fig a fost folosit pentru structurare ? da nu Ce Unde Când Care este gradul Orez Metoda de structurare a simptomelor de eroare datele disponibile Linia „Ce” listează simptomele comune ale erorii, linia „Unde” descrie locația în care au fost găsite simptomele, linia „Când” conține tot ce se știe despre când au apărut simptomele, iar linia „Ce grad” specifică amploarea şi severitatea simptomelor importanţa Să fim atenți la coloanele „Da” și „Nu” din tabel Ele descriu situații opuse care pot duce în cele din urmă la ipoteze de eroare Emiterea unei ipoteze Următorii pași sunt studierea relației dintre caracteristici și formularea uneia sau mai multor ipoteze despre cauza erorii, ținând cont regularităţi relevate în structura simptomelor de eroare Dacă nu pot fi formulate ipoteze, atunci sunt necesare date suplimentare, care pot fi obținute prin construirea și efectuarea de teste suplimentare În cazul în care sunt posibile mai multe ipoteze, se alege mai întâi cea mai probabilă dintre ele Dovada conjecturii Sărirea peste acest pas și săriți direct la concluzii și încercări de a rezolva problema este o greșeală gravă, care afectează de obicei rezultatul depanării Este necesar să se dovedească acceptabilitatea ipotezei înainte de a o lua ca bază Lipsa dovezilor duce adesea la rezolvarea „doar o parte a problemei O ipoteză este dovedită prin compararea acesteia cu simptomele sau datele inițiale ale erorii Trebuie să explice pe deplin existența acestor simptome Dacă nu se poate obține o astfel de explicație, înseamnă că ipoteza fie nu este fundamentată, fie incompletă, fie există numeroase erori De exemplu, să presupunem că în programul de clasare a testelor descris în Cap , a fost găsită o eroare evidentă Se pare că stă în faptul că mediana scorului de calitate a răspunsului a fost calculată incorect în unele, dar nu în toate cazurile Testul special a conținut înregistrări ale scorurilor de calitate a răspunsului a de studenți Valoarea medie a fost tipărită corect: , , iar valoarea mediană a fost în loc de valoarea așteptată de Luând în considerare rezultatele acestui test și al altor câteva, simptomele au fost grupate așa cum se arată în Fig Următorul pas este formularea de ipoteze despre eroare pe baza vizualizării rezultatelor programului și a inconsecvențelor Una dintre contradicții este că, aparent, eroarea apare doar la susținerea testelor cu un număr impar de elevi Aceasta poate fi o coincidență, dar este de mare importanță, deoarece numărul de studenți este par sau impar depinde de modul în care este calculată mediana De asemenea, pare ciudat că în astfel de teste mediana calculată este întotdeauna mai mică sau egală cu numărul de studenți ( ^ și ^ ) În situații ca aceasta, puteți relua programul pe un test care conține date despre de studenți cu scoruri diferite de calitate a răspunsului și puteți vedea cum afectează acest lucru calculul medianei î; da nu Ce În al treilea mesaj, valoarea mediană este tipărită incorect Calculul mediei sau abaterii standard Unde Doar E în al treilea mesaj În alte mesaje, notele elevilor par a fi calculate corect Când Care este gradul Când rulează un test care conține date despre de studenți Valoarea mediană este tipărită ca Un rezultat incorect se obține și la un test care conține date despre un student Valoarea mediană este tipărită ca ! La efectuarea testelor pentru și de elevi Orez Un exemplu de structurare a simptomelor de eroare Dacă acum mediana rămâne egală cu , în linia „Care este gradul” din coloana „Nu” se va scrie următoarele: „Valoarea medianei nu pare să depindă de valorile reale a estimărilor” Deși acest rezultat este un simptom important, s-ar putea presupune natura erorii fără el Din datele disponibile se poate observa că valoarea mediană calculată este egală cu jumătate din numărul de studenți rotunjit la cel mai apropiat număr întreg mai mare Cu alte cuvinte, dacă luăm în considerare valorile notelor așa cum au fost plasate în tabelul sortabil, atunci putem spune că programul imprimă numărul mediu de intrare al elevului, nu nota acestuia Prin urmare, ipoteza despre natura erorii este valabilă Această ipoteză trebuie dovedită prin verificarea textului programului sau efectuând câteva teste suplimentare METODA DEDUCEREA Procesul de deducere prezentat în fig , permite, pe baza unor teorii sau premise generale, folosind operațiile de excludere și rafinare, să se ajungă la o anumită concluzie (să se găsească locul erorii zhi) Revenind la exemplul unei anchete de omor, spre deosebire de metoda de inducere, în care suspectul este identificat prin totalitatea probelor, procesul de deducere începe cu identificarea cercului de suspecți, iar apoi prin excludere (grădinarul are Enumerarea cauzelor posibile Utilizând procesul de eliminare — Nskp ёсі Colectarea de date suplimentare ■foarte greșită Orez Proces de depanare deductivă „alibi rezonabil”) și clarificări (făptuitorul este un bărbat cu părul roșcat) concluzionează că majordomul „a comis crima Procesul de deducere este următorul: Enumerarea cauzelor sau ipotezelor posibile Primul pas este să dezvoltați o listă cu toate cauzele posibile ale erorii Aceste motive nu trebuie să explice pe deplin eroarea; sunt doar versiuni cu care poți structura și analiza datele disponibile Utilizarea datelor pentru a exclude posibile cauze Prin analiza atentă a datelor și (mai ales) căutarea inconsecvențelor (Figura poate fi folosită aici), toate cauzele posibile, cu excepția uneia, sunt excluse Dacă toate cauzele sunt excluse, atunci vor fi necesare date suplimentare (obținute, de exemplu, la construirea de teste suplimentare) pentru a prezenta noi ipoteze Dacă rămân mai multe motive, atunci se alege mai întâi cel mai probabil dintre ele, ipoteza principală Rafinarea ipotezei alese O posibilă cauză poate fi identificată corect, dar este puțin probabil ca aceasta să reflecte pe deplin specificul erorii Prin urmare, următorul pas ar trebui să fie utilizarea datelor disponibile pentru a rafina versiunea (de exemplu, „eroare la accesarea ultimei înregistrări a fișierului”) cu ținând cont de unele detalii (de exemplu, „ultima intrare din buffer suprascrie semnul de sfârșit de fișier”), Dovada ipotezei alese Acest pas este același cu pasul din metoda de inducție Ca exemplu, luați în considerare testarea funcțiilor comenzii DISPLAY (vezi Capitolul ) Să începem prin a rula patru dintre cele de teste corespunzătoare procesului prezentat în diagrama funcțională Inițializam starea memoriei astfel încât prima, a cincea, a noua, cuvintele conțineau valoarea ; al doilea, al șaselea cuvinte - valoare ; a treia, a șaptea, cuvinte - dimensiunea ; al patrulea, al optulea, cuvinte - valoarea SSSS Astfel, fiecărui cuvânt din memorie i se atribuie o valoare egală cu cifra hexazecimală cea mai puțin semnificativă a adresei primului octet al cuvântului respectiv (de exemplu, octeții FC, FD, FE și FF conțin valoarea C) Rezultatele testelor (așteptate și reale) sunt prezentate în fig Evident, la evaluarea acestor re- Intrări de testare Ieșiri așteptate Ieșiri reale DISPLAY E = Încălcare a sintaxei comenzii CCCC M DISPLAY - = CCCC = CCCC DISPLAY il = CCCC = CCCC = = CCCC DISPLAY M a solicitat memoria dvs - = - END iese din memoria reală = CCCC Orez Rezultatele testului de comandă Există unele probleme cu rezultatele, deoarece niciunul dintre teste nu a dat efectul așteptat (toate testele au avut succes) Să începem prin a identifica eroarea asociată cu primul test Comanda indică faptul că celulele E ( zecimale) ar trebui să fie afișate începând de la (nicio valoare până la punctul) (Reamintim că, așa cum se precizează în specificații, toate rezultatele de ieșire conțin patru cuvinte sau octeți) Pot fi enumerate următoarele cauze posibile pentru mesajul de eroare: S Programul nu acceptă cuvântul DISPLAY Programul nu acceptă numărul de octeți afișați Programul nu permite sărirea ca prim operand (adică se așteaptă ca numărul de octeți de afișat să fie precedat de o adresă) Programul nu acceptă E ca valoare validă pentru numărul de octeți Următorul pas este să încercați să excludeți cauzele Dacă toate cauzele sunt excluse, această listă ar trebui revizuită și extinsă Dacă rămân mai multe cauze, pot fi luate în considerare teste suplimentare pentru a găsi o singură ipoteză despre eroare sau pentru a trece la considerarea cea mai probabilă cauză Deoarece avem la dispoziție rezultatele altor teste, este ușor să stabilim că al doilea test din Fig exclude prima ipoteză, iar a treia, deși duce la un rezultat incorect, pare să excludă a doua și a treia ipoteză * În continuare, trebuie să clarificăm a patra ipoteză Această ipoteză pare a fi destul de specifică, dar intuiția sugerează că poate da mai mult decât pare la prima vedere, deoarece se manifestă ca o eroare similară, dar mai generală Se poate argumenta că programul nu recunoaște caractere hexazecimale speciale (A - F) Absența unor astfel de semne în alte teste explică pe deplin această eroare Cu toate acestea, înainte de a trage o concluzie, trebuie să luăm în considerare toate informațiile pe care le avem la dispoziție Al patrulea test poate afișa o eroare complet diferită sau poate oferi detalii suplimentare despre eroarea în cauză Cea mai mare adresă validă de pe sistemul în cauză este FFF, așa că nu este clar cum al patrulea test arată o zonă care pare a fi inexistentă Deoarece valorile valorilor afișate sunt setate și nu sunt constante interne ale programului, se poate presupune că această comandă afișează cumva conținutul unor celule cu adrese în intervalul - FFF De exemplu, o astfel de presupunere poate fi validă dacă programul tratează operanzii din instrucțiune ca valori zecimale (mai degrabă decât valori hexazecimale, care sunt specificate în specificație) Acest lucru este confirmat de al treilea stoma; în loc să afișeze de octeți de memorie, urmat de un increment de în hexazecimal ( în zecimală), testul arată octeți de memorie Acesta din urmă este în concordanță cu ipoteza noastră că „ ” este perceput ca o valoare zecimală Prin urmare, conform ipotezei revizuite, programul tratează conținutul unui octet, operanzii care conțin adrese de memorie și adresele de memorie pentru lista de ieșiri ca valori zecimale Ultimul pas este de a demonstra această presupunere Luați în considerare cel de-al patrulea test Dacă este interpretat ca un număr zecimal, atunci numărul său hexazecimal corespunzător va fi F , rezultând rezultatul Pentru dovezi suplimentare, luați în considerare al doilea test Rezultatul execuției sale este incorect, dar dacă și sunt tratate ca numere zecimale, atunci conținutul adreselor - D ar trebui să fie afișat, ceea ce se întâmplă de fapt Prin urmare, aproape sigur am remediat o eroare: programul tratează operanzii ca valori zecimale și tipărește adresele de memorie în același mod ca valorile zecimale, încălcând specificația În plus, această eroare pare să fie cauza rezultatelor incorecte pentru toate cele patru teste Astfel, raționamentul simplu ne-a permis să identificăm eroarea și, prin urmare, să rezolvăm alte trei probleme care, la prima vedere, păreau fără legătură Rețineți că eroarea apare probabil în două locuri în program: partea care interpretează comanda de intrare și partea care tipărește lista de ieșire a adreselor de memorie Pe de altă parte, această eroare, cauzată probabil de o înțelegere greșită a specificației, întărește ideea că un programator nu ar trebui să încerce să-și testeze programul Dacă programatorul care a făcut greșeala este și un scriitor de teste, atunci este probabil să facă aceeași greșeală atunci când scrie teste Cu alte cuvinte, rezultatele așteptate de programator nu vor fi aceleași cu cele prezentate în Fig Acestea vor fi evaluate presupunând că operanzii sunt valori zecimale Prin urmare, această eroare fundamentală în mod evident nu ar fi putut fi detectată INVERSIREA LOGICII O metodă eficientă pentru izolarea unui bug pentru programele mici este de a urmări logica execuției programului pentru a găsi punctul în care logica este întreruptă Cu alte cuvinte, depanarea începe în punctul din program în care a fost detectat un rezultat incorect (de exemplu, tipărit) Pentru acest punct, pe baza rezultatului obținut, trebuie stabilit (dedus logic) care ar trebui să fie valorile variabilelor Executând mental programul dintr-un punct dat în ordine inversă și raționând din nou ceva de genul acesta: „dacă în acest moment starea programului (adică, valorile variabilelor) a fost așa, atunci într-un alt punct ar trebui să existe următoarea stare”, puteți localiza rapid și precis eroarea (adică, determinați locul în program între punctul în care starea programului a fost așa cum se aștepta și primul punct în care starea programului a fost diferită de cea așteptată ) METODA DE TEST Ultima metodă de depanare bazată pe „gândire” este utilizarea testelor Această metodă poate părea puțin ciudată, deoarece la începutul capitolului am remarcat diferențele dintre depanare și testare Există însă două tipuri de teste: teste de testare, al căror scop este de a detecta o eroare predeterminată, și teste de depanare, al căror scop este de a oferi programatorului informații utile pentru localizarea unei erori suspectate Testele de testare tind să fie „abundente” (un număr mic de teste încearcă să acopere un număr mare de condiții), în timp ce testele de depanare încearcă să acopere o singură condiție sau un număr mic de condiții Cu alte cuvinte, odată ce este găsit un simptom al unei erori suspectate, această metodă este folosită pentru a scrie variații ale testului inițial pentru a încerca să izolați eroarea De fapt, metoda de testare nu este un fel special, exclusiv; Aceasta este adesea folosită împreună cu metoda de inducție (pentru a obține informațiile necesare la avansare ipotezele și (sau) demonstrarea acestora) sau cu metoda deducției (pentru a exclude cauze posibile, a clarifica ipotezele selectate și (sau) a le dovedi) PRINCIPII DE DEBUGARE Ca în cap , această secțiune discută o serie de principii de depanare, dintre care multe sunt de natură psihologică O serie de principii sunt intuitiv evidente, dar, în ciuda acestui fapt, ele sunt adesea uitate sau ignorate Există două seturi de principii aici, deoarece procesul de depanare constă din doi pași (localizarea erorii și apoi remedierea acestuia) Principiile localizării erorilor Gândi În secțiunile anterioare, depanarea a fost considerată a fi procesul de rezolvare a problemelor Cea mai eficientă metodă de depanare este analizarea informațiilor asociate cu simptomele de eroare Pentru implementarea sa eficientă, un specialist trebuie să fie capabil să determine cu exactitate majoritatea erorilor fără a utiliza un computer Dacă ajungeți într-o fundătură, amânați examinarea programului Subconștientul nostru este un mecanism puternic de rezolvare a problemelor Ceea ce atribuim adesea inspirației se dovedește a fi doar o muncă subconștientă făcută pentru a rezolva o problemă, în timp ce activitatea noastră conștientă în acest moment este asociată cu altceva, cum ar fi mâncatul, mersul pe jos sau vizionarea unui film Dacă nu puteți izola bug-ul într-un timp rezonabil (se presupune că de minute pentru programele mici, câteva ore pentru programele mari), nu mai căutați și faceți altceva, deoarece eficiența dvs va fi, în orice caz, redusă semnificativ Problema ar trebui să fie „uitată” până când fie găsiți în mod subconștient o soluție, fie vă odihniți și sunteți gata să reexaminați simptomele erorii Dacă ați ajuns într-o fundătură, prezentați problema altcuiva Făcând asta, probabil vei descoperi ceva nou Se întâmplă adesea ca doar repovestind o problemă unui ascultător bun, să găsești dintr-o dată o soluție fără niciun ajutor din partea lui Utilizați instrumente de depanare numai ca ajutor Nu utilizați aceste instrumente în loc să vă gândiți la problemă După cum s-a menționat mai devreme în acest capitol, instrumente precum depozitele și urmele reprezintă o abordare ad-hoc a depanării Experimentele au arătat că programatorii care evită utilizarea instrumentelor de depanare, chiar și atunci când depanează programe necunoscute, o performanță mai bine decât cei care folosesc aceste instrumente [ ] Evitați experimentarea Folosiți-l doar ca ultimă soluție Cea mai frecventă greșeală pe care o fac depanatorii începători este să încerce să rezolve o problemă făcând modificări experimentale în program („Nu știu ce este în neregulă, dar voi schimba acea declarație DO și voi vedea ce se întâmplă ”) Această abordare complet greșită este nici măcar nu poate fi considerată depanare; se bazează pe întâmplare Experimentarea nu numai că reduce probabilitatea de succes, dar adesea face sarcina mai dificilă, deoarece introduce noi erori în program Principii de corectare a erorilor Acolo unde există o eroare, probabil că există și altele Această prevedere repetă principiul cap , care afirmă că dacă se găsește o eroare într-o parte a programului, atunci există o mare probabilitate ca o altă eroare să existe în aceeași parte Cu alte cuvinte, bug-urile tind să se grupeze Când remediați o eroare, verificați mediul său imediat pentru orice simptome suspecte Găsiți eroarea, nu simptomul acesteia Un alt dezavantaj comun este eliminarea simptomelor erorii, nu eroarea în sine Dacă modificarea propusă nu elimină toate simptomele erorii, atunci aceasta nu poate fi pe deplin identificată Probabilitatea de a găsi corect o eroare nu este de % Cu aceasta, desigur, sunt de acord, dar în procesul de corectare a unei greșeli, se observă adesea o reacție diferită (de exemplu, „Da, în majoritatea cazurilor, acest lucru este adevărat, dar această ajustare este atât de mică încât este corectă”) Nu trebuie să presupunem niciodată că textul inclus în programul de corectare a erorilor este corect Se poate argumenta că revizuirile sunt mai predispuse la erori decât codul original al programului Implicația este că programul corectiv trebuie testat, poate chiar mai amănunțit decât originalul Probabilitatea de a găsi corect o eroare scade odată cu creșterea dimensiunii programului Această afirmație este formulată în moduri diferite Experimentele au arătat că raportul dintre numărul de erori găsite incorect și numărul celor detectate inițial crește pentru programele mari Într-un program mare conceput pentru utilizare pe scară largă, fiecare a șasea eroare nou descoperită poate fi făcută în timpul modificărilor anterioare ale programului Atenție la introducerea unei noi erori la corectare Este necesar să se ia în considerare nu numai ajustările incorecte, ci și cele care par corecte, dar care au un efect secundar nedorit și conduc astfel la noi erori Cu alte cuvinte, există șansa nu numai ca o eroare să fie detectată incorect, ci și ca corectarea sa să ducă la o nouă eroare Prin urmare, după ajustare, trebuie efectuată testarea de regresie pentru a determina dacă a fost introdusă o nouă eroare Procesul de remediere a unui bug ar trebui să readucă temporar dezvoltatorul în faza de proiectare Trebuie înțeles că corectarea erorilor este o formă de proiectare a programului Bunul simț ne spune că toate procedurile, tehnicile și formalismele utilizate în procesul de proiectare ar trebui aplicate și pentru corectarea erorilor, deoarece prin natura lor corecțiile sunt predispuse la erori De exemplu, dacă organizarea procesului de proiectare prevedea verificarea codului sursă, atunci este de două ori important ca acestea să fie utilizate după corectarea erorilor Modificați textul sursă, nu codul obiect' La depanarea sistemelor mari, în special a celor scrise în limbaj de asamblare, există tendința de a remedia eroarea făcând modificări direct la codul obiect (folosind un program precum „superzap”) pentru a modifica ulterior codul sursă al programului (de ex „când este timp”) Această metodă este de obicei un simptom al folosirii „depanării prin experimentare” În plus, codul obiect și codul sursă al programului în acest caz nu sunt identice, prin urmare, eroarea poate apărea din nou la recompilarea sau asamblarea programului Această practică arată o abordare neprofesională a depanării ANALIZA ERORI Depanarea unui program face posibilă nu numai estimarea costului remedierii unui bug, ci și obținerea de informații despre natura erorilor din software pe care cu greu le-am avut până acum Astfel de informații pot servi drept feedback pentru a îmbunătăți în continuare procesele de proiectare și testare Calitatea muncii fiecărui programator individual și a întregii organizații care efectuează programarea este îmbunătățită semnificativ dacă se efectuează o analiză detaliată a erorilor detectate, sau cel puțin a unui subset dintre acestea Această sarcină este dificilă și consumatoare de timp, deoarece implică mai mult decât o clasificare superficială, cum ar fi „Erorile X°/o sunt erori de proiectare logică” sau „Erorile Y% apar în instrucțiunile IF” O revizuire amănunțită poate include luarea în considerare a următoarelor întrebări: Când a fost făcută greșeala? Această întrebare este cea mai dificilă, deoarece răspunsul la ea necesită un studiu al documentației și al istoriei proiectului Cu toate acestea, aceasta este și cea mai interesantă întrebare Cauza inițială și momentul erorii trebuie determinate cu exactitate Aceasta ar putea fi, de exemplu, formularea neclară într-o specificație, corectarea unei erori anterioare sau înțelegerea greșită a cerințelor utilizatorului final Cine a greșit? Este util să arătăm că % dintre erorile de proiectare au fost făcute de unul din zece analiști sau că Programer X a făcut de trei ori mai multe erori decât alți programatori (nu în scopul pedepsei, ci pentru clarificare) Care este motivul erorii? Nu este suficient să stabilim când și de către cine a fost făcută o greșeală, este de asemenea necesar să aflăm de ce s-a întâmplat A fost cauzat de incapacitatea cuiva de a scrie clar, de o lipsă de înțelegere a anumitor constructe ale limbajului de programare, de o eroare de tastare sau de completare, de o presupunere greșită, de o incapacitate de a lua în considerare introducerea nevalidă? Cum ar putea fi prevenită eroarea? Ce s-ar putea face diferit în următorul proiect pentru a preveni acest tip de eroare? Răspunsul la această întrebare este cel mai valoros, deoarece vă permite să înțelegeți și să justificați cantitativ experiența de proiectare acumulată De ce eroarea nu a fost găsită mai devreme? Dacă o eroare a fost descoperită în timpul fazei de testare, este necesar să se clarifice de ce nu a fost detectată în fazele anterioare: în timpul verificării codului sursă și atunci când s-au luat în considerare problemele de proiectare Cum ar fi putut fi identificată eroarea mai devreme? Răspunsul la această întrebare este un alt exemplu de feedback util Cum pot fi îmbunătățite procesele de revizuire și testare pentru a găsi mai devreme acest tip de eroare în proiectele viitoare? Cum a fost găsită eroarea? Presupunând că nu analizăm erorile găsite de utilizatorul final (adică ne uităm doar la erorile găsite de test), trebuie să ne dăm seama cum a fost scris un test de succes De ce a avut succes acest test? Putem învăța ceva din el pentru a scrie alte teste de succes pentru a testa acest program sau programe viitoare? O astfel de analiză este, desigur, un proces complex, dar rezultatele sale pot fi utile pentru îmbunătățirea în continuare a activității programatorilor Prin urmare, este o problemă de îngrijorare faptul că marea majoritate a programatorilor și organizațiilor de programare nu îl folosesc LITERATURĂ Weinberg G M The Psychology of Computer Programming New York, Van Nostrand Reinhold, Gou d JD și Drongowski P A Controlled Psychologic-cal Evidence on How People Debug Computer Program — Int J Man-Machine Stud , , ( ), p - În rândurile AR și SampsonW A Depanarea programului Londra, Macdonald, LITERATURĂ ADĂUGĂ ÎN TRADUCERE V V Lipaev, Design of ACS software Inginerie de sistem Arhitectură Tehnologie M Radio sovietică, , p Sisteme de depanare a algoritmilor de control pentru un computer în timp real / Ed V V Lipaeva M , Radio sovietică, , p Lipaev VV Fiabilitatea software-ului ACS M , Energoizdat, , p A P Ershov, Introducere în programarea teoretică M , Nauka, , p Glushkov V M Cercetare fundamentală și tehnologie de programare - Programare, , nr , p - Golovkin B A Software de încredere - Radio electronică străină, , nr , p - E A Trakhtengerts, software ACS M , Statistică, , p P arhomenko P P , Pravilshchikov P A Diagnosticare software —Automatizare și telemecanică, , nr , p - Borzov Yu V Metode de testare și depanare a programelor de calculator Riga, Universitatea de Stat din Leningrad P Stuchki, , p Timofeev B B , Kozlik G A , Kulakov A F , Martyanov A I Algoritmizare în sisteme de control automate Kiev, Tehiika, , p I Fukem an A L Aspecte tehnologice ale creării sistemelor software M , Statistică, , p A G Mamikonov, A D Tsvirkun și V V Kulba, Automatizarea proiectării ACS M , Energoizdat, , p Ya E Aizenberg, B M Konorev, et al , Automated System for the Production of SINTERM Programs — În ki : Tehnologia programării Kiev, PC al Academiei de Științe a RSS Ucrainei, , p - Kolganova T V Criterii pentru testarea de planificare a verificării structurale a programelor de control Tehnologia de programare Tehnologia de depanare a programelor Kiev, IK AN USSRG , p - Bichevsky Ya Ya Construcția automată a sistemelor de exemple - Programare, , nr , p - B A Pozin, Metoda de construcție a testelor structurale pentru programele de control al depanării - Programare, , nr , Cu - Sistem unificat de documentare a programelor (ESPD) GOST - - - Myers G Fiabilitatea software-ului M , Mir , p Yodan E Programare structurală și proiectare de programe M, LIIR, , p Hughes J , M și h t despre m J Abordarea structurală a programării M , Mir, , p INDEX SUBIECTULUI Analiza valorii limită - de erori Biblioteci de testare Modificare în programe în timpul testării Specificație externă Evacuarea memoriei Inspecții la sursă Mesaje informative Clasa de echivalare Acoperirea combinatorie a condițiilor Complexarea Integritate conceptuală Criteriul de acoperire - completare controale Dovada matematică a cor- acuratețea programului Metoda „impactului mare” ra" — deducerea — inducție / Metode de „gros- ly" Modele de fiabilitate Modu l-driver -ștecher Fiabilitate agent independent- agenție de testare Variabila nedeclanșată Condiție prealabilă greșită Programare „anonim” Test de depanare — urmărirea logica în ordine inversă Erori la bit sau linia - intrare-ieșire - în mecanismele de control - interfata - atrage date ■— , a cărei manifestare depinde de datele prelucrate — în comparații — design Evaluare prin revizuire Planul de depanare - Apărare — teste — conversii Planificarea configurațiilor de testare echipament Acoperirea operatorilor ( ) - module — soluții — fiabilitate - - conditii - la limita Testare pas cu pas încărcări vaiiye - la limita Ipoteza de volum eroarea - în aval Președinte (dacă este corect inspecții) instalații Avertismente - programe precum Principiile de localizare a casetei albe coduri de eroare - programe precum " - depanare cutia neagră — testarea —• producător- Date de acceptare teste - proceduri Motivul - prin acoperire Verificarea la tabelul logica programului - rezultate - regresie » ansambluri (complete — sisteme dimensionare) ( ) — cerințe pentru design al structurii memoriei programe - cu aleatoriu Proiectarea unei intrări si (stochastice- tulpini șah) - teste - confort de utilizare Psihologia utilizării testării vaniya - comoditatea Imprimarea stării serviciului memorie - ușurință de instalare Vizualizări prin novki predispus la erori - comoditate părți ale programului operațiune Corolarul - funcțiile Specificații între punctele de întrerupere fata modulului Lista de întrebări pentru produsele gram detectarea erorilor tu în timpul inspecției Fazele de testare Standarde de scriere Funcțional dp- teste agrama Tabel de decizie Goluri Test de promovare-eșec Sensibilitate Testare împărțire) Împărțire echivalentă - recuperare runout — ascendent Economia testării — documentație vaniya 